Compass and map

Exploring, Pathmaking, Traveling

Lately Jess and I have been talking about the work of software development, particularly project setup.

Some of the work that we do when is purely experimental. “What happens when I push this button?” “What sub-commands are available?” “What is possible with this library?” “Will this fix it?” That’s exploring.

Exploring can be aimless. It can also be deliberate. We can make hypotheses and prove or disprove them. “I don't understand this framework, but I hypothesize that a change to this file will be be reflected in the UI”. This kind of code science can help us build a model: a limited theory of how software works.

This is like looking at the map and saying “I think that I'm here, and if I'm right that means when I walk two hundred yards East-South-East I'll hit a stream”. This is science, but “science” means a lot of different things to different people. So let's call this orienteering.

Exploring is only part of the work. Often we know approximately where we are, we know that a destination exists, and we are trying to get there. “The frob tool should be installed” “There should be customers in the database” This is traveling.

Traveling should be repeatable. It should be reproducible. Traveling should not involve a map and compass and some scribbled notes about “taking a left at the big tree”. The transition between exploring and traveling is accomplished with pathmaking.

Pathmaking can be as rudimentary as trailblazing. (Trailblazing is not as destructive as it sounds. It simply means delineating a path with “blazes”: periodic markings on trees.) This can mean writing a basic README.

Or pathmaking can be more robust, like clearing brush and shoring up a trail with stone stairs and logs for erosion management. This can take the form of of formal documentation, automation scripts, utilities, code generators, and many other conveniences.

The important thing about pathmaking is that the path exists in a known, shared, canonical location. Either the project repository (usually the best place) or a team wiki.

But sometimes we don’t make a conscious distinction between exploring and pathmaking. We get lazy and force other developers (including our future selves!) to repeat the same exploration over and over again. This is traipsing. We expect others to just traipse behind us, without any assistance.

Coding is inherently pathmaking. We figure out what needs to be done and and then we make a path that the computer can follow. Sometimes we even write it such that human readers can skim the individual steps and still see the overall journey. We call this readable code.

Setting up a new development environment for an established project often feels like exploring, but it shouldn’t. It should be traveling.

Jess has been exploring how to use Dockerized development environments to make setup repeatable. After some hesitance I think I’m on board. Computer horsepower is more of a commodity than it used to be, and being able to move a dev environment from one machine to another via checked-in configuration is a clear win.

Another, less implication of the exploring/traveling distinction: Data in development databases should be truly ephemeral and erased often. Is there data that is often useful to have? Then it should be captured in a seeds file, which is checked into the repository.

What are you doing right now? Are you exploring, pathmaking, or traveling?

Uncategorized November 12, 2019

On Gatekeeping, Complicity, and Arrival

The Ruby Rogues Years

Tell me if you’ve heard this one: four white guys ask a fifth white guy to join their podcast.

Being invited to Ruby Rogues in 2011, first as a guest and then as a panelist, was a thrilling moment for me. It was one of my first experiences of feeling like I’d “arrived”; like I’d achieved the acknowledgment and respect of my peers. It felt like a validation that I was competent and that I belonged. And over the following years it opened a lot of doors for me.

At the time, I didn’t think so much about how this is a privilege not everyone shares: the expectation that eventually, if you work hard, you’ll receive that kind of validation. How not everyone spends their life being implicitly told “that could be you, some day!”.

Fast-forward a few years. The Rogues panel had evolved considerably, but I had reluctantly quit because I had too many other calls on my time.

Charles Max Wood and John Sonmez

A few months after leaving, I became aware of the influence of John Sonmez on Charles Max (Chuck) Wood, the show’s founder. John, Chuck, and two other men hold weekly “mastermind” sessions where they talk about their lives and businesses, which they broadcast on a podcast called “Entreprogrammers”.

Listening to the show, I heard Chuck and the others publicly disparage, mock and plan to screw-over a friend of mine who was then working for him as a contractor. The man who took the lead in egging Chuck on: John Sonmez.

Sonmez’ creepy comments about women also stuck out to me. I remember being surprised that Chuck was so close with someone whose values seemingly clashed with (what I knew of) Chuck’s values.

For a while I also subscribed to Sonmez’ business partner Josh Earl’s newsletter. It was there I learned about some of the questionable marketing practices Sonmez was proud of. For instance, I learned about how John openly employed the tactic of directing mob pile-ons at people who upset him. I recently learned of another case of this, in which he used his mailing list to mass-downvote a less-than-stellar review of his book.

Over the years I would periodically think: at what point is Chuck going to finally get fed up with all this sleaze, and stop taking business and personal advice from this dude? Evidently the descent into full-on MRA pick-up-artist creepiness wasn’t enough. But when Sonmez recently went on a vicious, hateful tear telling black women on Twitter to “shut your mouth”, surely that was a wake-up call?

Civility

I went over to Chuck’s Twitter profile the other day, thinking I would DM him and ask him where he stood. I didn’t get very far though, because what I found were tweets defending Sonmez. Including a retweet of Robert Martin, snidely mocking everyone who was upset.

There was also a video. I watched it in full to make sure I understood Chuck’s position. He spends most of it complaining about how people aren’t being civil, and demanding that if people want to be heard they have to be nice and explain things carefully to Chuck and people like Chuck. He says he won’t defend what Sonmez wrote; but he can’t seem to bring himself to actually condemn some of the most hateful speech I’ve ever seen from a prominent developer. The whole thing comes off as petulant at the fact that people who have been held back by systemic sexism and racism for their entire lives, and are then told to “shut their mouths”, won’t behave themselves properly.

His proposed solution is to get John, a man who has publicly stated that he speaks in bad faith, together with the people he attacked for a “conversation”. 

Gatekeeping

At this point, I thought back on discussions with Chuck in the past. I thought about my Rogues days, and behind-the-scenes discussions of who to invite onto the show, or not. I thought about Chuck’s tweets and other public statements over the years. 

I thought about a recent case I’m aware of. In which a white guy was invited onto one of Chuck’s shows. Noting the lack of representation in the panel, the invitee proposed a woman who was more experienced than him on the same topic to go on in his place. He got silence in response.

And then I thought about silent gatekeeping. About those conferences that just happen to have stages dominated by white men year after year. And the organizers throw up their hands and say “nobody else submitted, these must be the only people available”. Even while other conferences show, over and over and over again, that they can achieve far more diverse speaker slates by widening the circles the organizers reach out to.

Complicity

And then I thought about complicity. Specifically, my complicity.

I thought about the guy that everyone in a group of friends knows is a little bit creepy toward women, but they hang out with him anyway and they don’t say anything because he’s basically a good dude, ya know? Or the guy who when he gets a few drinks in him at a party likes to bring up The Bell Curve and how different races have different IQs, it’s just science, but it’s not like he’s racist racist and so we all put up with him and don’t say anything.

Chuck isn’t either of those guys. But Chuck is nice-ist. He likes people to be well-behaved. Apparently without acknowledging that being nice just happens to be easiest for the people at the top of the heap.

With his position as the owner of popular podcasts for the Ruby, JavaScript, and freelancing communities, Chuck is in a position of great gatekeeping power in who he invites to be guests, and who he invites to be hosts. It’s a particularly influential position because, in my observation, developers typically do their most avid podcast-listening early in their careers. This is the period when they are absorbing norms. It’s the period in which they are learning what a Ruby developer, or JavaScript developer, etc. looks like, and sounds like.

And me… I’ve lent a little of my legitimacy to that empire. There are people who started listening to Ruby Rogues because I was on it. And at least in the back of my mind I’ve known for a while how those shows are implicitly curated.

In a world where marginalized people can sense that things are subtly weighted against them, but can never quite put their finger on how…  silence is complicity.

Repudiation

For years I’ve had a silent policy that I won’t go on any of his shows. I’ve turned down or ignored multiple invitations. I’m making that policy un-silent now.

I can’t magically withdraw any legitimacy I’ve lent to Chuck’s shows. But I can go on-record in saying that I reject any association between myself and those shows, other than my appearance in some of their back-catalogs. I can publicly state that after the mass panel departure two years ago, Ruby Rogues is not the same show I was once proud to appear on.

OK, enough salving of my conscience. Now for the important bit.

Tall Trees and Monoculture

I went on a hike today. Along the trail there was a tree that was so completely rotted out inside that I could fit myself, with my backpack, in the open hole in its side. But remarkably, there were still leaves on its branches. The end for that tree is unavoidable, but it may continue to shade out younger trees and inhibit their growth for another decade or more.

Prominent people and resources in the developer community can feel like that tree. It can feel like “ah, this thing already exists, there is no reason to make one like it”. Many aspiring bloggers despair of what to write, because they are afraid that anything they might write about has already been said.

The truth is, just because a thing exists doesn’t mean it’s the best thing or the authoritative thing. For instance many have noted that John Sonmez’ book on soft skills and career development is… not actually very good. There are others who write far more deftly and wisely on that topic.

Monoculture promotes laziness and mediocrity. One of the reasons I am thrilled to see the software industry gradually becoming more diverse is because of how much the quality of writing and speaking about software has improved as a result.

Facilitating Arrival

I’m not here to try and get Chuck to change. The only way we’re going to have reliably better representation of diverse voices in software is if marginalized people are the ones creating and owning the resources. My role here is to lift up the next generation of bloggers, authors, speakers, show hosts, and screencasters.

So, a few things:

  1. If there’s already a blog, a book, a podcast, a YouTube channel, but you think: “I could do that, and better”… You may well be right. Do it. Don’t let the prior existence of resources or “authorities” hold you back.
  2. I want to help. I’ve created and hosted podcasts, written books, given talks, made screencasts. I’ve done many of these things professionally, and I’ve helped a lot of other people do them too. I’m happy to help with advice, encouragement, feedback, and rubber-ducking. If you’re a member of a marginalized community, you’re working on an idea for developer-facing media, and you want to talk to someone about it, hit me up.
  3. If you know someone who is already doing this and kicking ass, please tell me about them so I can draw attention to them.

Eight years ago when I arrived on Ruby Rogues, I felt like I’d arrived. I want that feeling to be readily available to everyone who has something to say in the developer community. I want to help make sure more saplings get the sunlight they need to thrive.

Community October 28, 2019
Dust and microorganisms microscopic view

Simple is Complex

I started reading Vehicles, by Valentino Braitenberg. Braitenberg asks us to consider the implications of extremely simple notional machines. For instance, the very first machine has only a single motor controlled linearly by a single sensor.

If we say that the sensor senses heat, then this machine will move faster in warm areas (seemingly trying to escape them) and slower in colder areas. If we then add small “perturbations” to its environment—say, water currents, or other objects randomly nudging it—it will appear to wander around in a rather “lifelike” manner. It will appear to have a kind of purpose, even though we know it is nothing more than sensor and motor.

Braitenberg demonstrates how adding only a few more elements to such a vehicle vastly increases the richness of its behavior.

Vehicles with only two sensors and two motors can appear to display tendencies towards an energy emitter that we might term fear, aggression, or love, if we didn't know we were looking at a simple machine.

What if we again add some sources of random perturbations and throw a swarm of these ultra-simple machines together and allow them to also perturb each other? We get a system of extraordinarily complex emergent behavior… even though the individual elements are about as simple as we could imagine.

To restate: this system is not complicated. But it is complex.

Now consider a Chad Fowler-style microservice architecture (or Fred George-style, if you prefer). E.g. microservices so small that they fit on a single screen. We don't rewrite or add to them; we throw them away and make new ones.

These services are simple. But throw them all together, interacting with each other and perturbed by real-world inputs, and what do we get? Emergent, unpredictable behavior and interactions.

This is a system that is not complicated. But it is complex.

Or in other words: Simplicity leads to complexity.

This isn't a bad thing. Complex systems are rich systems. But living with them requires a graceful approach. We very quickly pass the point at which it is feasible to understand the system, let alone predict it. Instead, we need to be able to deeply observe the system, mitigate failures (but only after the fact!), note trends, and nudge it in new directions.

Design Uncategorized September 26, 2019

Rails 6 errors: the good, the bad, the ugly

Lately when I'm supposed to be getting actually useful things done, I find myself procrastinating by writing code instead. I have a Rails 6 codebase I've been fiddling with.

The other day as I did some reload-driven-development, I got this error:

The Good

Wow, development-mode error screens have come a long way since Rails 1. There's so much information here!

First off, there's the exception, the full path, and the message.

Then a nice source code listing with the error highlighted.

Followed by a trace with selectable app and framework filters.

Then there's a bunch more essential contextual info.

Then we get to the real doozy: an interactive REPL embedded right in the error page.

I showed this to a friend who is familiar with Java and JavaScript web frameworks and she was like, “whoah”.

The Bad

Ruby's auto-suggestion is great, until it's not. Here, the suggestion of the mysterious video_path is worse than useless. There is no “video” concept in the application, so what even is this referring to? Presumably, somewhere in the thousands of methods known to the entire Ruby VM, it found a method called video_path. This is going to be a “wait, what!?” moment for anyone who doesn't understand just how broad the auto-suggest feature can be.

But why is it even looking for a votes_path method? Well, here we get to the actual problem, which is that votes_path.canvass was nil.

It was only the fact that I have a fair amount of experience with Rails form helpers that led me to realize that the fact it was looking for votes_path instead of canvass_votes_path, despite the nested resource array given to model:, indicated that maybe .canvass was missing. I have no idea how a Rails newbie would have figured this out. The fact that form_with happily breezes by a nil in the supplied array without so much as a warning is… unexpected.

The Ugly

It does not help in diagnosing the problem, that the apparent receiver for the incorrect route helper method is an inscrutable collection of symbols and hex. This is why, when I do metaprogramming that involves on-the-fly class or module generation, I like to generate a helpful name for the new class/module while I'm at it. I'm tempted to see if I can find where this class is being generated and submit a PR. At least in dev mode, it would be nice to have a meaningful generated moniker.

Rails July 7, 2019
screenshot of gleek.io

Tools for turning descriptions into diagrams

Sometimes I have a picture of a software design in my head and I just want to draw it. If I don't need to collaborate with anyone remotely I might just draw it freehand. For collaborations and for diagrams I might want to iterate on, a tool like LucidChart can be really handy.

But sometimes I just want to list concepts as I hear them, fill in the connections between them, and let a computer worry about layout. That's what the tools below are all about. The particulars of each tool differ, but all of them let you enter a simple text description, e.g.:

Read More

Tools June 21, 2019

How to relax your Ruby version specification in your Gemfile

Have you ever run into this error?

Your Ruby version is 2.6.1, but your Gemfile specified 2.6.3

Annoying, right? You know your Ruby version is new enough to run this application, but the Gemfile is so fussy.

Turns out, Gemfiles don't have to be so picky. Just like you can relax version dependencies for gems, you can also make your Ruby version specifier less specific. As with gems, the secret is using the tiddly-waka (~>) operator:

ruby '~> 2.6.0'

Now this project will run with any patch version of Ruby 2.6 without complaint.

Ruby June 21, 2019

SIGAVDI #55: Lavender Yogurt Edition

Hello friends,

I just got back to Tennessee after a wonderful couple of weeks in St. Louis. Hey look, here's another pairing video with Jess! I wanted to deepen my understanding of TypeScript, so we started implementing one of my go-to “learn a language” programs: a text adventure game.

TypeScript is boring, but that's kind of the point. And it has some nice type inferencing.

BTW, Jess has a newsletter and if you like this one you will love hers.

​

​

Something I realized in conversation with Jess this past week: technologies and practices often act as proxies for culture.

You want to adopt microservices but really you want small feature teams to be able to act independently and quickly.

You wanted Linux in the server room but really you wanted a culture of sharing instead of information-hoarding.

You wanted Spring instead of J2EE but really you wanted a culture of open-source.

You want Kubernetes but really you want a culture of developers taking responsibility for delivery.

You want chaos engineering but really you want a culture of resilience to the unexpected.

Very often, we don't consciously realize that a desirable technology is really a stand-in for a desirable culture. And in the absence of culture adoption, the technology fails to deliver the hoped-for benefits.

Technologies and practices evolve in a context: a context of culture. How do we import the culture and not just the tech? We can't adopt culture by taking a course or reading a book.

Cultural adoption requires making contact with the society that has adopted the culture already. We have to attend their meetups and conferences. Follow them on Twitter. Maybe hire some of them.

​

​

I watched a movie called Liberal Arts last night. It was well-written but ultimately not worth the time I put into it, except maybe that it prodded me to think about the reasons I didn't like it.

Our society is full of moralizing stories and books and movies about the Man's Journey: how he sets out to seek his fortune and defeat his predecessors, and then, victory in hand, he returns home and accepts his proper role as a settled, contented, somewhat diminished pillar of society. A stabilizing influence and mentor. Jung talked about this narrative a lot. Joseph Campbell decided all myth everywhere was about this one story.

(Where is woman in this story? Oh, she's there to support the Hero, give him a motivation, and to help him sort through his feelings, obviously. 🙄)

I spent the first part of my life trying to skip directly to the last bit, and I've since decided it's overrated. I don't want to be anyone's pillar. I'm here to know less, feel more, and eat tacos.

​

​

This week kicks off almost two full weeks without my indispensable assistant Robin. She's on much-deserved computer-free vacation. It'll be interesting to see how I fare without her constantly greasing the wheels and lightening my email load.

​

​

What I'm grateful for this week: The card game Fluxx, and especially Cthulhu Fluxx. These games are a bit like Calvin Ball: the rule is that the rules always change.

This week's chosen meetup: KnoxPy!

Let's see how I did:

  • 😞 Book summer camps for the kids. I filled out all the forms for the camp they really wanted and then found out it was completely full. I still need to look into alternates, but I already know most of them are too expensive for me.

  • ✔ Start on getting 2018 non-biz numbers to my accountant. This was easier than I'd feared because it turned out I'd kept YNAB up to date last year. I need to get on the ball for this year.

  • ✔ Write an anxiety-inducing email. Done, and it didn't go over as badly as I'd feared.

  • 😐Finalize Let’s Make a Chatbot in Ruby as a product, and prepare for launch. I didn't get as far as I'd hoped with this, but I did start to break the one big video down into ~15-minute sections.

This week:

  • At least finish breaking up the videos for Let’s Make a Chatbot in Ruby

  • Get ready for the kids arriving for the summer.

  • Put some thought into scheduling: how am I going to spend time with the kids and also meet work commitments?

And that's plenty for this week. As always, thanks for reading, and please reply with your thoughts.

Cheers,

Avdi

SIGAVDI June 5, 2019

SIGAVDI #54: Watermelon Salad Edition

Hello friends,

This week I am in St. Louis, visiting Jess. As usual, we’ve been yelling at code together and streaming it (video 1, video 2).

Oh oh oh before I get into the rest of this email, I just wanna say I’ve been working super hard on getting my new chatbots video ready for sale. It has a proper name now: Let’s Build a Chatbot in Ruby!

And I made a cover graphic!

And you can buy it in beta for $15! I’d love to get some more beta customers to give me feedback on it 😁

OK, shameless self-promotion out of the way…

​

​

Once I was employee #1 in a funded, incubated startup. The investor/advisors made sure that the founders had all their ducks in a row. Accounting! Payroll! Legal! Branding! Lean startup coaching! Office space! Networking!

And, of course, hiring staff, i.e., me. Which was nice for me, but probably a bit premature in retrospect.

It all seemed to keep the founders quite busy, right up to when the startup folded. I’m not going to claim that all this legitimacy theater was the cause of the company’s failure; ultimately it was a matter of insufficient product value. But I submit that the distractions didn’t help.

Since then, I’ve observed this same phenomenon from the middle distance, via friends and colleagues, at a lot of funded startups. I believe it is possible to give a startup just enough money to waste all of its’ time.

Having money leads to spending money, and spending money costs time. Spending other people’s money costs even more time. You have to perform due diligence to reassure yourself that you’re spending the money well, and the more money, the more time it costs.

Here’s the important bit: a lot of legitimacy theater is about managing risk. E.g. what if by failing to do a full legal review, we omit a line in a contract, and fail to give ourselves the option of suing an incompetent contractor?

But this omits consideration of the opportunity risk: what are we risking by dithering and expending cycles on dotting Is and crossing Ts? What if in the meantime, that contractor decides to move forward with a different opportunity?

My theory: if you look at the early history of of successfully bootstrapped (non–funded) companies, I suspect you’d find a lot of fudged procedures in the beginning. They made handshake deals instead of running everything through legal. They sorted the books out after the fact.

There’s the Way Things Are Done, and then there’s the way they actually happen.

​

​

This week I’ve been making a concerted effort to write some Actual Code (see those videos above), which means turning my travel machine into an Actual Coding Workstation.

For reasons I might go into in another newsletter, I’m committed to developing on Windows systems these days. Over the past year I’ve done enough Rails and Node development with native Windows to decide, once and for all, that it’s a non-starter. By “native”, I mean: using Node or Ruby interpreters + libraries compiled for Windows.

(These days it’s not so much a Microsoft/Windows problem as an ecosystem problem: any nontrivial Ruby or Node project has hundreds or thousands of third-party dependencies (packages, tools, etc.) and every five minutes some open-source developer out there introduces a Windows regression into the latest version of a gem or package. Not out of malice, mind you, but just because they don’t have access (or time) to test on a Windows box. Much of the time it’s not a simple regression, but an interaction between packages/tools that results in an error.)

So. Fully-native development is out. But! After a fair amount of time exercising it, I can happily say that Windows Subsystem for Linux (WSL) is fucking amazing and a real game-changer. We can now install Ubuntu, Arch, Fedora, etc. directly from the Windows Store, and in my experience it Just Works.

No recompiling, no container boot times, no massive memory usage, no SSHing, no setting up filesystem mappings, no port mapping. Just pop open a WSL terminal, install needed packages straight from distro repos, and code away, using a combination of native and Linux tools. There are some I/O efficiency issues when working with thousands of files (cough NPM cough), but the recently-announced WSL2 promises to address this.

This week I took things a step further and installed VS Code Insiders so I could play with the new Remote Development support, and it’s super cool. It transparently runs editor extensions on the remote side. Whether “remote” means over SSH, via Docker, or local WSL instance. This means that, for instance, a code-linting extension will automatically run using the target development environment, instead of behaving subtly differently because it’s running on the “client” side.

​

​

What I’m grateful for this week: I feel like I basically covered that above: WSL. Also, frequent flyer points that take me to see the people I love.

What meetup I’m going to this week: none, while I’m in St. Louis. But I can report that I had a nice time meeting folks and learning about WebPack at last week’s KnoxJS!

Let’s see how I did:

  • ✔ Livestream with Jess, since I'll be in St. Louis. Done! See above.

  • ✔ Pre-sell and get started marketing the chatbots video. Done!

  • ❌ Book a Rubber Duck Session or two. Nope. I had one potential session that I had to cancel because I got sick 😭

  • ❌ Pick a first business metric to track and figure out how to track it. Nope.

  • ❌ Book summer camp(s) for the kids Ugh, nope.

This week:

  • Book summer camps for the kids.

  • Start on getting 2018 non-biz numbers to my accountant

  • Write an anxiety-inducing email

  • Finalize Let’s Make a Chatbot in Ruby as a product, and prepare for launch.

That’s it for now. See you next week!

SIGAVDI May 28, 2019

SIGAVDI #53: Tamale Edition

Hello friends,

I'm on my mom's back porch on a sunny Sunday in Knoxville. Last night I spent a solid 6 hours dancing and socializing at my favorite club night. Today I feel pleasantly fatigued and a bit languid.

A minute ago I looked up one of my old blog articles and was struck by how much of an asshole I used to be. When I started blogging I was strongly influenced by the tone of early popular blogs, which were mostly White Men Having Smug Opinions About Things. I guess I thought: ah, this must be how you make a name for yourself: have loud Hot Takes about everything, and criticize the writing of people with a bigger following until someone takes notice of you.

At first I thought this was just a stage everyone passes through. But as I think about it more I wonder if it's a patriarchy pattern. Something something hero's journey, something something Luke Skywalker, something something kill your father-figure.

Joseph Campbell is an interesting read but boy oh boy, dude had a one-track mind. I've read Hero with 1,000 Faces, and listened to his famous interview series with Bill Moyers. And what came across was less that the same archetypes are repeated over and over, and more that Campbell had one big idea and found ways to see it everywhere.

Hm, this is a cautionary tale when it comes to me and my obsession with seeing processes. Also, I just criticized the pattern of tearing down an old guy by tearing down an old guy 😂

I still have lots of opinions, albeit with lower confidence. Hm, actually, let me quote the article I just linked:

The loudest, most bombastic engineer states their case with certainty, and that shuts down discussion. Other people either assume the loudmouth knows best, or don’t want to stick out their neck and risk criticism and shame. This is especially true if the loudmouth is senior, or there is any other power differential.

Diverse members of your team may be less likely to have experienced the collegial, open debate environment, and may feel uncertain of their position. This means you might not hear their ideas. Given the extensive research that shows diverse teams make smarter decisions, this is tragic.

Even if someone does have the courage to push back, in practice the original speaker isn’t likely to be holding their opinion as loosely as they think. Having stated their case, they are anchored to it and will look for evidence that confirms it and reject anything contradictory. It is a natural tendency to want to win the argument and be the smartest person in the room.

Once upon a time, Cardboard Tube Swordplay (CTS) wasn't considered a legitimate sport. If people had heard of it at all they generally sneered at it. If it appeared in popular culture at all it was usually as the butt of jokes.

One way or another, the early CTS players (“tubies”) found each other. They recognized kindred spirits and started having meetups and even conventions. Slowly, painfully, and with many arguments they hammered out the sport we all know and love today.

Where once there was just a vague, amorphous area of overlapping interest, the tubies created boundaries and categories. They created the classes of competition – longtube, paper towel, packing tube, etc., along with standardized tube gauges. They came up with quantified ways to rate and rank competitors. They agreed on safety regulations. They composed the Rites of Challenge. Leagues were formed. Eventually, twelve recognized Tube Masters gathered together and authored The Way of the Tube (WotT), which defined (among other things) the path of tube ascendancy: how a novice must apprentice to a series of masters before finally confronting the Cardboard Gauntlet.

By defining boundaries of what was and was not CTS, the tubies conferred legitimacy on themselves. When outsiders would make uneducated claims about tubies being “a bunch of kids beating each other over the heads with foam swords”, the CTS community was able to push back and tell them that, actually, headstrikes are banned, duels are carefully refereed, and styrofoam is never involved. Steadily the sport gained recognition and serious coverage.

A generation passed, and a funny thing happened. What was once a sport for nerds and weirdos became a pop culture phenomenon. Where once a novice could spend months searching for a Tube Master to train them, now thousands of YouTube videos offered “how to” tutorials. Accelerated training “tubecamps” sprang up all over the world.

A new breed of tubies arose: ones who had never faced the tubie stigma; had never been derisively told to pick up a “real sport”.

And these nu-tubies showed no respect or even gratefulness to the old guard. They scorned the apprenticeship system. They made stupid mistakes and created unnecessary drama that never would have happened if they had just adhered to the Rites of Challenge. They introduced outlandish new elements such as pool noodles.

Many established CTS authorities questioned whether this new guard were even “real tubies” at all. Some elders, including several of the WotT authors, began pushing for a tubie certification program. They created cults of personality, recruiting impressionable younger tubies searching for a sense of identity, teaching them to sneer at “damp tubies” for being insufficiently disciplined.

The free-thinking youngsters, in response, accused the old-timers of “gatekeeping”. They pointed out that some CTS traditions such as the Cardboard Gauntlet were more like hazing rituals, which discouraged prospective players. They noted that the old guard seemed to all come from the same socioeconomic background and questioned whether toxic CTS culture was keeping the sport from becoming more diverse.

More importantly, they asked, wasn't CTS originally supposed to be about having fun, not about parsing rule manuals?

The elders replied: This kind of fun is serious business. We created this game out of chaos. We painfully won our recognition, the recognition that you now enjoy. This is our game, and you can't play it if you don't play it right.

What I'm grateful for this week: The DJs, staff, and everyone who attends my local goth/industrial night. It's an inspiring, cathartic, restorative experience every time I go, and I've met so many wonderful friends through it.

What meetup I'm going to this week: well I'm off to St. Louis on Wednesday, but I might be able to make KnoxvilleJS. I haven't been to that one yet.

Let's see how I did:

  • ✔ Get two me-authored RubyTapas episodes ready for the team. Done. Two more episodes on async are moving forward into production.
  • ✔ Get another episode of The Cache Flush out. Done, and you can find it here
  • ✔ Keep working out on a daily basis. Maybe not every day, but I get a few five-mile runs and a night of dancing in, so ima call that a win
  • ✔ Edit that video about building chatbots in Ruby. Done! I'm excited to move forward into publishing and marketing this one.

This week:

  • Livestream with Jess, since I'll be in St. Louis
  • Pre-sell and get started marketing the chatbots video.
  • Book a Rubber Duck Session or two. Want me to sit down with you and talk code, architecture, career, or other? Get in touch!
  • Pick a first business metric to track and figure out how to track it.
  • Book summer camp(s) for the kids

 

That's plenty for today. Thanks for reading, and stay in touch!

SIGAVDI May 19, 2019
1 2 3 … 59