Monday, March 28, 2016

Follow up to my Babel 6 rant

I wrote a blog post yesterday ranting about Babel 6. It was posted to Hacker News and viewed 10,000 times within one day.

It's the next day and my head is cooler so I want to say a few more things.

The first thing to acknowledge is my great appreciation for the hard work that open source developers do. They choose to contribute their time and considerable professional expertise writing software for free.  That's no small deal, so I say thank-you to the Babel 6 developers.

Babel 6 is amazing.  Being able to compile ES2015 and have it run on any browser is a true game changer.  ES5 is a real pain and I am eternally grateful to those people who enable me to write ES2015 instead of ES5.

The reason people bother to complain about something is that they care about that thing.  If they did not care then they would simply be indifferent. So the origin of my rant is that I am clearly deeply involved in the usage of Babel 6.

The thing I value more than anything is my own time.  I have nowhere near enough time.  It is my most scarce resource. So when software causes me to lose time in very large chunks, I get extremely frustrated.  Writing a rant like that is the outcome of months of losing vast chunks of time to Babel 6 configuration.  It's not a spur of the moment hotheaded outburst.

And although I delivered the message to the Babel 6 folks in an overly pointed manner, sometimes there is value in people receiving not only a message but also the level of emotional intensity.  The rant level of intensity is far more likely to draw the attention of the message recipient than a quietly spoken, factually driven list of issues posted to github.

An effective rant, whilst certainly emotional, should not be a personal attack on people.  Hopefully this one was not.

And for the recipient of a rant, it's an opportunity to hear from your software users who are deeply engaged .  As a software developer it can be very hard to grasp how a user experiences your system, so when you get a rant hopefully it is not just an attack but contains valuable insights that can help the developer to understand the user experience .

So thanks to the Babel 6 folks for an excellent product.  I'm not at all backing away from the content of my rant but I do want to color it further with my appreciation for your work, and indeed for the work of all open source developers.

Sunday, March 27, 2016

Babel 6 - useless by default - a lesson in how NOT to design software.

One of the hardest things about learning modern JavaScript programming is wrapping your head around the build systems - all the non-programming stuff you have to get going to run your code.

And for mortal humans it is *really hard* to grasp what the heck this complex ecosystem of build tools does and how they fit together, how to configure them and how to drive them.  REALLY hard.  Beginner JavaScript programmers who wish to do modern development face a massive learning curve just to get started. If you think it's easy then have climbed the learning curve and done your learning already and forgotten how hard it was.

So the easier the build tools are to install and use, the better.  Ideally, for common use cases, the end user will need to do precisely nothing apart from install the build tool to get basic and even advanced level usage out of it.

And Babel is one of the core parts of that build system.  It compiles ES2015 code to ES5 that can be run on any browser.

Out of the box, Babel doesn't do anything.  Literally useless by default.  Want to do something?  You MUST configure it.  And of course that means you have to start learning how to drive and configure Babel.

The first step in learning a new system is the hardest and most confusing and most time consuming.  To configure one tiny thing a vast array of questions come up.  Am I really meant to do this?  Should I be changing this setting?  Why do I need to do this? What does it do?  Am I breaking something?  Are there more things to configure? Am I working with the latest information or has the system changed since the documentation I am reading?  Why have I found three sets of conflicting instructions to do this configuration? And the biggest question of all - why do the instructions on this web page not match what I see on my screen? And then of course, "I've made the changes as instructed, why doesn't it work, what's wrong?". All these questions come from a hazy fog of ignorance of what the software is, how it holds together, what it's purpose is and why it works the way it does. You groan inwardly and sigh - fuck, how deep is this "simple" rabbit hole going to be? EVERYONE goes through this phase of learning a new technology.

If a build tool requires the user to make even one single configuration setting then they have imposed a huge learning cost on that user.  Possibly many hours of time and possibly (even probably) failure in trying to reach their goal.  For many users the cognitive load will be too high.  And the user may not even succeed in doing configuration that the developers consider to be basic and trivial.

Conversely, if a build tool requires a user to configure *absolutely nothing*, then they have saved the end user hours and driven them to a "pit of success".

Too many JavaScript build tools think that developers care about the build tool.  They think that developers want to understand the build tools, and want to learn and configure and program those build tools.  I'm not here to program build tools.  I am here to program application code.  I want my JavaScript build tools to anticipate likely use cases, come pre-configured to do as much as possible out of the box.

Experienced Babel 6 users will dismiss my assertion that configuration is hard. "It's easy!" they'll say.  You change one file: .babelrc, npm install your presets, install your plugins and modify your update your webpack config and you're good to go!  It's 60 seconds work so you are speaking garbage. "

Experienced developers forget how incredibly hard and time consuming and confusing it is for unexperienced users to do those 60 seconds worth of tasks.

It should only be necessary to configure JavaScript build tools for optimisation of final production code.  Forcing users to configure everything up front is premature optimization, wastes users valuable time, imposes a cognitive load on the user and makes the entire JavaScript development process massively more complex and hard and for some users trying to get started, will kill their enthusiasm and will kill the entire process for them

So when Babel 6 decided that it would do nothing out of the box, it did the opposite of conventional wisdom in software usability, which is to include sane defaults that anticipate the most common use cases and provide them, ideally with zero requirement for setup and configuration.

Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc.  They should throw everything in there that a developer might want to use.  The expert use case for Babel is to strip it down to the minimum.  It should not be the basic use case to build it up to usable. I shouldn't need to even think about how to configure Babel until I'm so far into my development process that I have already scaled the other learning curves that were essential such as learning ES2015 and browser programming.

Babel wants to exist, be seen and heard and talked about.  But in fact it is plumbing that you should really never have to give a thought to unless you're walking a very unusual road.  Babel's demands for you to configure it is like your taps in the kitchen needing you to get under the house with the wrench and hook up the hot water yourself, install a hot water tank, install solar panels and set the temperature in order to use it.  Not stuff you should need to do.  Babel should generally be neither seen or heard.  The Internet should not be plastered with blog posts instructing you on how to configure Babel, some right, some wrong, some out of date, some conflicting.  The developers should have configured it once, properly, so you don't need to think about it.

And finally, the cost to the Babel project itself is support issues and questions and problems from people who haven't managed to get things to configure, or didn't even know they were meant to configure - only that something isn't working.  The Babel project is shooting itself in the foot and making work for itself. The Babel developers should always be focused on how to reduce and remove the need for configuration, to find effective ways to preconfigure, and to find ways to allow people to use Babel with ever less knowledge that it even exists.

OK I'm headed back to see how to configure Babel to use async and await.  I really wish it was configured out of the box. What a waste of time.

P.S. and by the way I do know about Babel presets. That's too much configuration too.  The right amount of configuration is none.

Saturday, March 5, 2016

Get ready for our first civil war against robots - here's what it will look like.

Clearly we are already in a world in which robots are an integral part of war.  Nations use robots to fight against each other and against terrorists.

So far, however, we have not had a civil war against our own robots - against the robots who serve us. But that civil war against our servant robots is coming.  And sooner rather than later.

The first civil war against our own robots will be the battle against driverless trucks, which are, of course, robots.

In France, taxi drivers protested against uber.  It got violent.  The taxi drivers face losing their income to this disruptive force.

But the French taxis drivers protest has three constraints that prevent it turning into an all out war:


  • The first constraint is that it's not easy to identify an Uber car - they look like any other car, so it's hard to target them.  
  • The second constraint is that even if Uber cars could be easily identified, there's a natural reluctance to direct violence at them because Uber drivers are people and there are significant consequences for directing violence at another person.
  • The third constraint is that whilst there are alot of taxi drivers, there's not a huge number of them.  Wikipedia says that in the United States in 2012 there were 233,900 taxi drivers.


The war against robot trucks will have no such constraints.


  • Driverless trucks are big and hard to hide, and they have no driver, which makes them easy to spot and thus easy targets. They are unprotected.
  • There are no people in driverless trucks, so if done carefully, they can be attacked with minimal risk of hurting humans. The consequences of violence against robots are not as harsh as the consequences of violence against humans (yet).
  • According to the American Trucking Association there are over 3 million truck drivers in the U.S.A.  That's alot of potential "combatants" against the robots.

Driverless trucks will mean that alot of people lose everything, and when people have nothing to lose they become more willing to respond in an extreme manner.

There will be a war against driverless trucks.  It's gonna be a big one.  It will certainly be explosive and it's coming to the streets near you.






Wednesday, February 3, 2016

A full stack developer is only half as focused as a half stack developer

Stop obsessing about employing full stack developers.

JavaScript front end development is more than enough for one person to specialise in.

It is to your advantage to employ people who want to focus only on the front end.

I am seeing employers who insist on people being full stack and as a result miss out on getting great developers who are focused entirely on the web browser front end.