YARP (Yet Another Rant about Programming)

Imagine that, as a kid, you really wanted to learn an instrument.  Eventually, after lots of nagging, and some luck, your parents get you a cheap $50 guitar.

Excited, you strum the guitar, imagining that you will hear the overdriven birth cry of of some guitar-rock god, even though your guitar is acoustic, and you have no amplifier.  Instead, you hear shit.  And your hand starts cramping.

But, no matter.  Undeterred, you convince your parents to buy you some books, or videos on how to play the guitar, and slowly, you learn the ropes.  While all your peers spend their time in sports, or playing video games, you spend yours honing your guitar skills, until one day you are so good, that your parents to get you a professional guitar, and amplifier.  Equipped with this new tool, you transcend your previous limitations, and you decide that you wish to dedicate the rest of your life to being a musician.

So, you go to music school, where, to round you out as a musician, they require you to learn piano, some wind instrument, music theory, and composition.  No sweat.  Yes, there are many differences between the skills that guitar requires, and what these other disciplines require, but much of what you have learned, while playing guitar transfers over.

Sure, you never formally learned what a key was, or any of the myriad scales, but years of guitar playing had prepared you enough so that it wasn't too difficult to learn these new rules.

Then, you graduate, and are immediately hired as the guitar player for a band.

That's when the trouble starts.

You see, in school, they didn't tell you about what makes a professional musician valuable, and, in fact, you are surprised to learn that it is not actually knowing how to play one of several instruments, or even knowing music theory.

No, what makes a musician valuable is staying up to date with the latest instruments.

In fact, every year, a new instrument that purports to be more versatile, cheaper, and have better sound quality, than the previous year's instrument, is released, and unless you keep up to date with these latest models, you quickly become outmoded by your peers.  In fact, most of your peers already know these technologies, and they're the ones given all the cool solos, while you are stuck as a backup, or working with sound levels on recordings, which, by the way, are required to be released every two weeks--more on that in a second.

That Les Paul you got in 2010 is so yesterday.  These days, everybody uses a Xerxes Ubaphone with an Apache Goliath RDSS to release their latest tracks.

You don't know what an Ubaphone is, or what a RDSS is, but you jump in, and try learning it.  After all, you have years of music school, and self-education under your belt.  How hard could it be?

Well...

So, you find out that a Xerxes Ubaphone is not actually an instrument in itself, but, rather a complex framework of different connectors, for different instrument parts.  This is why it's so flexible.  With Ubaphone, you can create virtually any instrument you want, which seems pretty cool.  Except for the fact that it is so complex that its manual is 500 pages.  On the other hand, it has a thriving online community of musicians, who use it.  In fact, it was created by musicians, and is open source.

Additionally, you find that RDSS stands for Remote Distributed Sound System.  This is not your father's sound system.  No, it is a scalable, high fidelity, sound system that enables you to layer over millions of tracks simultaneously, and broadcast it over a virtually unlimited number of speakers, with sophisticated nose filtering technologies, which eliminates sound clipping, feedback gain, and other such nuisances.  And these speakers can be anywhere in the world, in relation to each other.

Sounds pretty cool, right?

Well, it also has a manual of 500 pages.  On top of that, its documentation assumes that most of its users have experience with an Ubaphone, so that, while it can hook into a regular instrument, all of its examples require you to have a fully deployed Ubaphone of some kind working.

Oh, and that if you use Xerxes Ubaphone, it needs be be a 2018 version, because previous versions had a vulnerability that, despite the Goliath RDSS' claim to eliminate feedback gain, could lead to a severe feeback gain, which tended to blow out half of the speakers in the sound system.

You groan, but you're a good sport.  So, you set about reading the manuals, and start with the Ubaphone.  The first thing you find is that, when you first unpackage the Xerxes Ubaphone it does not come ready to use.

Nope!  You have to configure it, by setting a bunch of dials, and buttons, and to your dismay, even though what you're reading claims to be a manual, it fails to provide even one example of a basic configuration that you can use in most reasonable cases.  Instead, it tells you to consult a chapter on "Configuring for different backends."

Not sure what a backend is, you look up this chapter, only to be assaulted with a slew of different types of configurations for things you have never heard of, with names that fail to convey what they actually do:

Apache Vindaloo, Skrunk, GPI, Zogaz, and so on...

It turns out that you can't just learn Xerxes Ubaphone.  You have to be familiar with at least one of these technologies.

That's because a Xerxes Ubaphone does not actually handle transformations of sound signals between parts, but only offers an interface for doing so.  The thing that really transforms sound signals is called a backend, and is handled by one of the gadgets above.

Well, Apache Vindaloo, like all Apache Musical Foundation products is well supported with a thriving online community--and a 500 page manual.

At this point, since you have already wasted half a day on documentation, you don't wish to read yet another fucking manual.

So, you try to see if there is some quickstart guide to setting up Apache Vindaloo, which, heavens be praised, you find pretty quickly.

In fact, it is published by Apache, so if anything, it should be the authoritative source on setting up Xerxes Ubaphone with Apache Vindaloo quickly, right?  Right?

Well, so far, it seems that way.  It turns out that even though the manual didn't mention it, the Xerxes Ubaphone comes preconfigured to work with an Apache Vindaloo, and, in fact, the Vindaloo comes with all 2015 distributions, and later--and that was that mysterious thingamagig you found bubblewrapped, and unlabeled with your Ubaphone.  Even better, the quickstart guide tells you precisely the steps to follow to get a basic Xerxes Ubaphone with an Apache Vindaloo Backend up and working, and even throws in attaching a Goliath RDSS!

So, you follow it, and by the end of the day, you now have a fully configured system.  Excited, you press a key, AND IT DOESN'T FUCKING WORK.

It turns out that the quickstart guide was published in 2015, and is outdated.

This process continues for a week, until, finally, after days of talking with fellow musicians, and desperately scanning forums and google groups, you identify the problem: the Ubaphone requires a specific up-to-date power adapter, and apparently, this was such common knowledge to anybody who had ever used an Ubaphone, nobody ever bothered to mention it.  You find this out, after the lead musician berates you, asking you what kind of musician you are anyway, if you don't even know something so basic?

If you think this is the end of your woes, you are sorely mistaken, my friend.  You see, the other major thing about modern professional musicianship nobody fucking bothered to tell you is that musicians are treated like mules.  In fact, a methodology of producing music has taken the music industry by storm.  It is known as VERSATILE, and all managers, and producers love it, even though it is the scourge of the earth.  What distinguishes VERSATILE from previous ways of producing music, like improvisation, and traditional composition, is that it is a results-driven methodology built around the following mantra:

"Release musical tracks early, and often."

All the biggest labels follow this methodology, because it offers a reliable way to mass-produce music that everybody listens to.

To achieve this goal, VERSATILE prescribes the following practices, and guidelines:

1. Split up your planning into 2-week long intervals called "sprints."
2. Each sprint is expected to enrich the current track being produced with new features, or patch errors in the existing track.
3. Frequently release of variations of the same music track.  It doesn't matter, if the track lacks a resolution, or that the vocalist stutters during the final verse, or that the 2nd verse is just the lyrical filler, "Boodabee, Babbadoo, Quabbawee, Shabbadoo", because they lyricist couldn't think of clever enough lyrics.  That can be fixed with the next sprint.  Just get a minimum viable track out there.
4. Speaking of which, whenever developing a track, just focus on short-term, realizable goals.  In fact, focusing on the long term, and painstakingly working out a plan for making a masterpiece is frowned upon by management as emblematic of the old way of doing things, which, you used to call "giving a damn about your art", but which they call the CATARACT approach.  In fact, CATARACT is used by everybody in the music industry to derisively refer to any practice that doesn't conform with VERSATILE, even if it fits your workflow better than anything VERSATILE has to offer.

The worst part about VERSATILE is how it is abused to force musicians to work 60-80 hour workweeks.  You see, because you need a minimum viable track in 2-week sprints, the producer doesn't want to hear it if, say, your efforts of laying over your Ubaphone track configured for Les Paul Acoustic Guitar were hampered by the lack of support for Les Paul Guitar, even though he requested it.  You had better figure something out, and fast!  Better get yourself a pot of coffee, and say goodbye to coming home to your wife and kids, tonight!

If you are thinking to yourself, "No musician would ever want to become a professional musician under those ridiculous constraints," it is safe to say you are not alone.

On the other hand, the above scenario is precisely the kind of bullshit that professional programmers have to go through, every fucking day.

In fact, I was inspired to write this rant, as a result of attempting to deploy something called JanusGraph, and the process of learning it is not too far off from the preposterous Xerxes Ubaphone scenario I mentioned above.

Look, I don't expect programming to be easy.  Writing code that does nontrivial things correctly, efficiently, and works as expected in other machines but the one you wrote it on is difficult.  I accept that.

What I have difficulty accepting is the other bullshit--this whole process of spending 70% of my time understanding an ever changing suite of tools instead of actually using them.  These tools purport to somehow make my life better and increase my productivity, but they don't, because I can't actually do my job until I have mastered configuring them in the first place, and then I have to scramble in the little time I have left to create a minimum viable product so that my manager isn't shit on by his manager.

In fact, this is such a problem that I often prefer to write my own utility, rather than suffer the dependency, and configuration hell of learning a new library, or framework.  Don't chastise me for reinventing the wheel, when learning how to use any of the available ones requires me to expend weeks of mental energy just getting it to roll--weeks that I could have devoted to actually doing something interesting--programming!  What a novel concept!

Look, I know that documentation is hard, and interfaces evolve, but there's got to be a better way of doing this, because it is not the programming that I fell in love with.  Hell, it isn't even programming!