Performance Engineer vs. Tester

A performance engineer’s job is to get things to work really, really well.

Some might say that the difference between being a performance tester and a performance engineer boils down to scope. The scope of a tester is testing, to construct, execute and verify test results. An engineer seeks to understand, validate, and improve the operational context of a system.

Sure, let’s go with that for now, but really the difference is an appetite for curiosity. Some people treat monoliths as something to fear or control. Others explore them, learn how to move beyond them, and how to bring others along in the journey.

Testing Is Just a Necessary Tactic of an Engineer

Imagine being an advisor to a professional musician, their performance engineer. What would that involve? You wouldn’t just administer tests, you would carefully coach, craft instruction, listen and observe, seek counsel from other musicians and advisors, ultimately to provide the best possible path forward to your client. You would need to know their domain, their processes, their talents and weaknesses, their struggle.

With software teams and complex distributed systems, a lot can go wrong very quickly. Everyone tends to assume their best intentions manifest into their code, that what they build is today’s best. Then time goes by and everything more than 6 months old is already brownfield. What if the design of a thing is already so riddled with false assumptions and unknowns that everything is brownfield before it even begins.

Pretend with me for a moment, that if you were to embody the software you write, become your code, and look at your operational lifecycle as if it was your binary career, your future would be a bleak landscape of retirement options. Your code has a half-life.

Everything Is Flawed from the Moment of Inception

Most software is like this…not complete shit but more like well-intentioned gift baskets full of fruits, candies, pretty things, easter eggs, and bunny droppings. Spoils the whole fucking lot when you find them in there. A session management microservice that only starts to lose sessions once a few hundred people are active. An obese 3mb CSS file accidentally included in the final deployment. A reindexing process that tanks your order fulfillment process to 45 seconds, giving customers just enough time to rethink.

Performance engineer doesn’t simply polish turds. We help people not to build broken systems to begin with. In planning meetings, we coach people to ask critical performance questions by asking those questions in a way that appeals to their ego and curiosity at a time that’s cost effective to do so. We write in BIG BOLD RED SHARPIE in a corner of the sprint board what the percentage slow-down to the login process the nightly build as now caused. We develop an easy way to assess the performance of changes and new code, so that task templates in JIRA can include the “performance checkbox” in a meaningful way with simple steps on a wiki page.

Engineers Ask Questions Because Curiosity Is Their Skill

We ask how a young SRE’s good intentions of wrapping u statistical R models from a data sciences product team in Docker containers to speed deployment to production will affect resources, how they intend on measuring the change impact so that the CFO isn’t going to be knocking down their door the next day.

We ask why the architects didn’t impose requirements on their GraphQL queries to deliver only the fields necessary within JSON responses to mobile app clients, so that developers aren’t even allowed to reinvent the ‘SELECT * FROM’ mistake so rampant in legacy relational and OLAP systems.

We ask what the appropriate limits should be to auto-scaling and load balancing strategies and when we’d like to be alerted that our instance limits and contractual bandwidth limits are approaching cutoff levels. We provide cross-domain expertise from Ops, Dev, and Test to continuously integrate the evidence of false assumptions back into the earliest cycle possible. There should be processes in place to expose and capture things which can’t always be known at the time of planning.

Testers ask questions (or should) before they start testing. Entry/exit criteria, requirements gathering, test data, branch coverage expectations, results format, sure. Testing is important but is only a tactic.

Engineers Improve Process, Systems, and Teams

In contrast, engineering has the curiosity and the expertise to get ahead of testing so that when it comes time, the only surprises are the ones that are actually surprising, those problems that no one could have anticipated, and to advise on how to solve them based on evidence and team feedbacks collected throughout planning, implementation, and operation cycles.

An engineer’s greatest hope is to make things work really, really well. That hope extends beyond the software, the hardware, and the environment. It includes the teams, the processes, the business risks, and the end-user expectations.

Three, Sixty, Five

In less than three days, I recently passed through five airports using six planes to meet with three very important teams. Not a single Uber (because fuck Uber), 14 meetings/calls later, and a collective 9 hours of sleep. Before I let the normal hurricane of work-life sweep these events away, I want to distill learnings.

First…Context:

In 2017 after an exhaustive job search, I found myself talking with an SMB CEO about what my goal was. I said then, as I still say now, that one of my primary goals is to “be in the room”. Rooms where decisions are made; not only internal decisions, external ones too. You have to prove your value at the table in these rooms, and this is what I do.

Three

During these past three days, three very meaningful things happened.

One: an F100 customer I’ve invested a ton of effort in for the past 6 months demonstrated how impactful that work has been to their strategic quarterly planning in front of two very important people in the full-time company I work with. This took me by surprise, but is exactly what happens when you’re doing things right (I think). People benefit so much they want to share it with others. I see this as a positive characteristic of humanity.

Two: another F100 prospect I’ve invested a ton of time with confidentially shared how the internal dynamics of their big-picture financial strategy over technology funding underscores the importance of having a flexible approach to the acquisition process for software vendors and GSI partnerships. I would never have had the opportunity to learn this in school, at prior software jobs, or without the support of an amazing business team (incl. key individuals in leadership, partner channel, sales, and product management).

Three: I got another very private F100 customer to discuss patterns, practices, and industry trends with a senior researcher at a major analyst firm. Early in my career and for many people in what I refer to as ‘shallow engagement work patterns’, this would be impossible; but I believe in value-first relationships, referring to how Tim O’Reilly puts it: “create more value than you consume”. Really doing this with your customers takes more than an ask, it takes gives which make asks pale in comparison.

Sixty

These and other things happened the past almost-three days, but took sustained efforts. The same statement applies every day inside my day job. Some things happen overnight. Some things aren’t under your control. That leaves the universe of possibility to things that happen over time and are totally under your control. This is very good news for us “busy brains”.

Self-control is a characteristic people pick up on subconsciously, but lack thereof most certainly triggers conscious flags. I have a few habits…nail-bitten fingertips, post-its written everywhere, late-night emails…that I think qualify for the latter. In contrast to the last sixty hours, I’m going to scale back these and other habits over the next sixty days. This will take effort, sustained and supported with the help of others.

A colleague said to me last month: “don’t wait for your doctor to tell you”. Habits are something that can be changed. Trust takes time to build and can be lost overnight. Observing people’s habits can accelerate identifying trustworthiness. Being someone I know is trustworthy, I want to seek ways to accelerate others’ trust in me. Controlling habits is my immediate actionable.

Five

If you’re ambitious, curious, and capable, tech is a fantastic sector to be in. Things move very fast, money too. Five years ago, I very deliberately pivoted my career from writing code all day to observing and directing the code that people operate by. In retro, I could have done this in my early twenties, but at least it’s happening now.

Since 2018, the rooms I’ve gotten really good at working in are typically at an F100. Under the surface, things in F100s are so complicated and fucking messy…I love it when things are messy…but on the shiny topside in rooms with egos and initiatives and collateral on the line, dialogs have to be squeaky clean. The trick is how to bring the room together with anything but the mundane, with active listening, informed point of view, inspiring next-challenges, and most importantly, sincerity. Effective communication and collaboration takes experience, and experience takes doing. This is what I’m doing all the time now, honing and refining.

Holiday IoT and the Performance Imperative

A few words to manufacturers and vendors of tech toys: to really be ready for the holiday, if your product requires software updates in order to work or is in any way internet connected, make sure your site stays up. Otherwise, you just shipped coal.

  • Provide more than one distribution point for downloadable updates/binaries
  • Rely on CDNs for static assets (like installers and documentation)
  • If your update process must rely on live services, make sure they’re scalable
    • Load test subcomponents/microservices AND the end-to-end process
  • Be prepared for damage control by:
    • Monitoring site uptime and availability to know when things are broken
    • Proactively establish a communication channel with customers during issues
    • Properly staff IT and support for during AND post-season issues
  • Make sure the cost of downtime is factored into your next sales cycle

Santa Brought Us a Brick?

Let me start by admitting how 1st-world this example is. Robots as play-things are still not exactly ‘so easy, a child could do it’, and Roomba’s have been around for almost two decades, but we still have yet to see a really down-to-earth home robotics project that really works for children under 10. I don’t just mean toys that are not pre-assembled, even the right-out-of-the-box kind often require firmware updates or online services to really work as expected.

Case in point, the Meccano MAX. Though it only took about 3hrs total to put together, this morning when we finally turned it on and went to connect for a firmware update, the vendor’s website was down…hard. The instructions said, before anything else, update the ‘MeccaMind’ and voice commands weren’t working without, so, blocker.

As an ops nerd, I slapped an uptime monitor on it to know when (if ever) it was back up:

That didn’t stop the whole multi-day experience from deflating to a dud. We all worked on this thing together and then before it can do anything, we are stuck guessing about when we can actually enjoy it. Don’t blame Santa, blame the geniuses at Meccano.

Performance, of your product, of your service, of your site, is imperative to delivering what you sold people. Availability, uptime, scalability, and reliability matter by default now. Everyone has downtime, but 4hr recovery time on your corporate domain isn’t just irresponsible and costly, it’s plain embarrassing…and transparent.

Why Is This Even Important?

My 7yr old is crazy into coding right now. Granted, we use a visual Code Block Editor mostly for lights and tones, but it’s a great way to introduce concepts like flow control and formal logic. As soon as she saw an example I built that used function blocks to encapsulate and reuse logic, she instantly understood and started refactoring her programs.

But finding the right project for varying stages of aptitude, appetite, and enjoyment is a real challenge. No thanks to marketing, but also unanticipated road-blocks like service and subscription dependencies are hard for consumers to factor in when purchasing. Even when you do find a right-fit project, if bone-headed problems like website downtime occur, it can become a negative experience for the child (or student).

It’s important for STEM product manufacturers and software vendors to really think about the impact of what they’re selling, how they’re delivering it, and how to support people who paid them money for something to accomplish a goal. If you don’t have the optimal consumer’s experience in mind, it will eventually cost you.

Need the Robot Software Updater?

I can’t archive everything on their site, and it’s their job to provide reliable content distribution, but in case you find yourself stuck like I was, here are links to at least the firmware updater tool:

Also, never ask a consumer if they want to choose (null).

And if the updater gives you flashbacks to DirectX drivers from 1997, don’t worry. It only looked like it bricked my robot for about 4mins before providing UI feedback:


Once you do get back to the modern era, a 98.6MB mobile app to control it shouldn’t be too hard on your data plan. They also need to know your GPS location, phone contacts, and file storage for some reason.

Value Chain in DevOps

Foreward: Since I highly doubt the following concepts will see the light of day in the final draft of IEEE 2675, I wanted to document that in fact I pushed this to the group June 15th 2017. During a subsequent review, it got huge push-back from our Curator in Chief, the early first of a future string of events that lead me to publish this primary work on my personal blog.

What is a ‘value chain’?

value chain is a set of activities that a firm operating in a specific industry performs in order to deliver a valuable product or service for the market. The concept comes through business management and was first described by Michael Porter in his 1985 publication, Competitive Advantage: Creating and Sustaining Superior Performance.[1]

The idea of the value chain is based on the process view of organizations, the idea of seeing a manufacturing (or service) organization as a system, made up of subsystems each with inputs, transformation processes and outputs. Inputs, transformation processes, and outputs involve the acquisition and consumption of resources – money, labor, materials, equipment, buildings, land, administration and management. How value chain activities are carried out determines costs and affects profits.— IfM, Cambridge[2]

[Wikipedia: Value Chain (Porter)]

How does it related to IEEE 2675?

As related to DevOps, the Value Chain for Software Delivery is an application of a lifecycle perspective that scopes standards adherence to only certain individuals based on their participation in primary or supporting activities related to a particular software product.

DevOps is about continuously delivering value to users/customers/consumers. A value chain perspective disaggregates activities from an organizational funnel, making it easier for teams and consumers of a particular product or service to ask “does this thing meet the standard” without unintentionally including other unrelated teams or products, were the question be phrased as “does this organization meet the standard”.

What problem are we solving by using ‘value chain’?

Adoption. In large organizations with many independent groups or product teams, DevOps principals may apply across the value chain of one product, but not another, provided these products are completely independent from one another. For an organization or team to claim that a particular software product adheres to this standard, all aspects of that product’s value chain must implement the principals and practices set forth in this standard.

Examples of where the broadness of using “organization” presents a challenge to adoption:

  • Consulting agencies with many independent project teams on working on separate contracts/products
    • If only one of those contacts require adherence to 2675, does this require every team/contract (both in the future and retroactively) to do the same?
    • Using “value chain” would scope 2675 adherence to any and all parties performing activities germane to delivering that specific contract/product
    • We know that if even one team implements DevOps per 2675 and sees success, organizations are likely to grow that out to other teams over time; “value chain” helps adoption of the standard. 

  • Enterprises in the midst of transformation to DevOps
    • Can they claim adherence on a specific product if the “whole organization” can’t yet?
    • Much like the above agencies argument, when the scope of adherence is based on activities relating to delivery of a project, enterprises are far more capable of becoming “DevOps ready” because they can grow the practice out *over time*
    • In DevOps, key success factors are determined – driven – by customers, the end user.

  • Organization’s requirements from non-technical internal agencies
    • Can we expect that the legal or HR departments are also “DevOps”? 
      This would of course need to be defined by activities that support the delivery side of the business (i.e. billing, purchasing, etc.), begetting an activities-based perspective on implementation over organizational labeling

Why is this of importance to IEEE 2675?

In layman’s terms, adoption of IEEE 2675 at an organizational level can’t happen overnight, especially in large enterprises with many teams. Fortunately, it doesn’t have to, provided we adequately scope ‘shall’ statements with a perspective that A) is reasonable in scope and impact on the org, and B) enables parties to agree on what it means for a software product to have been developed and delivered using this standard.

How and where would we use ‘value chain’?

Places in the text where use of the word ‘organization’ could infer that IEEE 2675 must be implemented across the whole organization before any single team or product could claim adherence to the standard. For instance:

  • Too broad:

    “Organizations shall implement effective continuous delivery procedures aligned with the architecture definition in a manner that meets the business needs of the system.” … “DevOps itself requires effective architecture across the organization to ensure that application build, package and deployment procedures are implemented in a robust and consistent manner.” (6.4.4)

  • Scoped: 

    “Organizations shall implement effective continuous delivery procedures within a particular value chain that are aligned with the architecture definition and in a manner that meets the business needs of the system.” … “DevOps itself requires effective architecture across the whole value chain to ensure that application build, package and deployment procedures are implemented in a robust and consistent manner.”

  • Too broad: 

    “Organizations shall maintain an accurate record of both code deployed and fully automated mechanisms in order to remove obsolete code.”

  • Scoped:

    “Organizations shall maintain an accurate record of both code deployed and fully automated mechanisms in a value chain in order to remove obsolete code.”

Additional references:

Wanting vs. Having for My 7yr Old

I make a lot of mistakes. I try not to do it on Github where commits are a permanent record of your competencies. So are children, only the impact of a word said harshly or missed opportunity for positive reinforcement take immediate effect and often have lasting effects on their lives.

Taking my son and daughter out one-on-one to get gifts for the people in their lives is important to me, and despite sometimes feeling like it in the moment, is never a mistake in the ideal sense. Having a positive experience doing so is also part of a successful outing, because if it’s a negative experience, the whole thing is useless.

A few weekends ago, I went out with my daughter. When we finally ended up at the toy store to get something for her brother, naturally she found something for herself. Because she’s seven, and no matter how zoned in of a quick pow-pow we had outside before entering about who she’s here to shop for, she still looks at the world with her-eyes. Arguably we all do this, regardless of our age, defaulting to looking out for number one in all manner of situations. That day, it was a cheap, pink, plastic set of glam rings.

I said no, but I’ll think about it, and asked her to put them back and focus on her brother’s gift. What a mistake. She didn’t throw a fit or get weepy or shut down. I took a picture (for when I would come back in search of stocking stuffers) and moved on. The Big Day is a week away, and I realize there was a missed opportunity there and I have to find a moment with her when she gets them in her stocking to make this memory-point:

In life, the moment you want a thing and the moment you get it are often different.

If I had bought her that thing, what next? Should she have it right then, as inevitably she would. This is just kicking the ‘delayed gratification’ can down the road. And in juxtaposition with the notion of immediate positive reinforcements, her want wasn’t connected to a prior goal or reward plan. So no, I don’t just buy things because my kids want them, even when I can. It’s not just the principle that matters, my choices (a.k.a. commits to their codebase) have an immediate impact. The manner in which I roll those decisions out matters as much as the very moment of desire in their hearts.

So what will I do with this new hypothesis? As with all hypotheses, I will test it. On the morning of the Big Day, after all the things are unwrapped and people chill the fark back down and people have 2nd coffees and there’s bandwidth for sharing that learning, I will say to her:

“Love, I too seek the desires of your heart and will always support you in them. In life, the moment you want a thing and the moment you get it are often different times. Remember this thing, what you wanted weeks ago? Well I remembered and it’s been waiting for you the whole time. But there’s a time and a place, which is today! Trust in me, one who has gone before, that I can help you learn to deal with the waiting time between when you desire something and when you achieve it. Remember that my love for you is something you don’t always know how to see, but never doubt that it will always be there.”

AllDayDevOps 2018: Progressive Testing to Meet the Performance Imperative

Mostly as an appendix for references and readings, but whenever I can I like to have a self-hosted post to link everything back to about a particular presentation.

My slides for the presy: https://docs.google.com/presentation/d/1OpniWRDgdbXSTqSs8g4ofXwRpE78RPjLmTkJX03o0Gg/edit?usp=sharing

Video stream: https://www.youtube.com/watch?v=DexfpnbBFn8

A few thoughts from my journal today (spelling and grammar checks off):

Will update as the conversation unfolds.

 

Adhocathon: Selenium Conf Chicago 2018 – Rstats in Grid

The goal of this time-boxed, scoped hackathon is to visualize the health and activities of a Selenium Grid instance by contributing the code necessary to report key metrics via Statsd. This supports observability and operational reliability requirements of continuous testing “at scale”.

Date/time: Thu Oct 18th, 6-8pm in the LaSalle room

Sign up here: https://goo.gl/forms/SztY8j7j83RZQEkJ2

Why Selenium Grid and Statsd?

Out of the box, visibility into how Selenium Grid is working/performing can be…limiting. This is a problem, because when a test fails (maybe multiple times), how can you quickly know where the issue originated (app, test, environment, data) if all of these things are not easily observable?

…and because lots of people use both of these technologies, or at least should, and they are both premised on separation of concerns at architecturally significant points, such as test-vs-environment and business-logic-vs-logging. Also, this is a stated potential area of focus for improvement by a few of the Selenium core contributors, and because the Statsd protocol has extremely wide-spread support in the industry.

Why So Last Minute at the Conference?

A few weeks ago while helping to organize DevOps Days Boston, I had a mental breakthrough about why testing gets talked about very little in organic DevOps communities: much of automated functional and non-functional testing doesn’t speak the same lingo as development and operations.

One of the core DoD organizers, Laura Stone, had just published a set of training videos on Statsd which I was impressed with, learned something from, and it struck home that we don’t have telemetry for Selenium Grid, a focus of my recent pet project during the day.

Many large organizations I work with use WebDriver extensively, and in order to fit something as critical as functional testing into a DevOps-minded delivery pipeline, software components and services must be operationally visible. The health of supportive dependencies, as they contribute affinities and deficiencies, are often as important as the health of primary deliverables.

So I had the courage to reach out to my volunteers’ contact at Selenium Conf Chicago about an idea I had on contributing to the Selenium project, namely layering in Statsd functionality into Selenium Grid to improve the observability.

Why Is This Not a Hackathon?

My ideas are shit. Not always, but most of life is an opportunity to learn what you don’t know. A majority of hackathons typically structure as a competition for prizes, and typically gravitate around some narrow vendor offering or are staged solely to promote some new service. Some business sets the tone and parameters, then judges contributions based on a set of meritable characteristics. This is not what I want.

In every area of my professional life, I look for opportunities to listen, learn, and deliver value. What better way to do those things that get a lot of other people to do them with you, multiplying the chances of exfoliating great ideas rapidly! The closest I know to this idea is a hackathon, but much of the work to getting the best ideas out quickly isn’t coding; it’s necessary, but often not the most relevant outcomes. So I needed a new name: “ADHOCATHON” is an iterative, time-boxed design-code-deliver session format.

How Is It Going to Go?

I have no idea. I often get these things right, like last month when I got 40+ managers together as a meetup to have a “forward dialog” about hiring and recruiting challenges and tips in the current Boston tech climate. The point is not that you know what to expect, but that you can facilitate the “best” outcomes to become a useful contribution.

That said, the conference organizers were happy to help however they could, and now we have a room at the venue right next to the first-day reception area. I have a number of customers and colleagues signed up to be there. There will be tweets going out via the conference handle. And I will have found my way into the place that Tim O’Reilly describes as “creating more value than you capture”.

For the next few days, I will be scrambling to provide minimalistic resources to accomplish this goal, such as:

Whatever happens, it will definitely be interesting. I’ll publish a follow-up article on what happened and outcomes here after the conference ends.

 

Engineering Is About More Than Code

Curiosity is what drives engineers, and is equal parts curse and companion. An engineer isn’t limited to development or operations. An engineer would be a problem-solver in both areas, probably more. Curiosity is a surprisingly rare quality in people, even in technology.

If you want to know how something works, take it apart and observe. My first digital systems disassembly was a Sony Discman in 1989. Whatever I did, I fixed it. The feeling was powerful. It just took me 25 years to realize that there are many broken things in the world and to prioritize which one’s I involve myself with. Understanding the problem is crucial.

This is how I approach many conversations, navigating purposely and politely until there’s a useful reframing. People aren’t things, so be kind, be sensitive, and be patient. When you engage, learn about their biggest challenges, how they approach things, and what drives them. Just start with that.

[If my 80’s discman was still around, it would be like “yup, those were the days”. My 8086 XT clone next to it would splutter out some op codes. My Mega Man game watch would be waterlogged and stuck in a loop. Which all lead me to the next action…]

Put things back together again so that they work, hopefully, better than before. It’s just courtesy. In commit-worthy code that’s called hygiene. In conversation, that’s called maintaining a shared view or vision. Do these things enough and you’ll find that the way to a common goal is easy easier than with clutter obscurring your journey, and for others’. When you can row in the same direction, you get to your destination a whole lot faster.

Put it with other things to see where it doesn’t work. That’s integration and it’s not always easy, especially if it’s your own code or new auto-scaling configuration that causes unforeseen things to blow up. Get to know what your thing does before and after you put it out in the wild. Be honest with yourself and others about the time this takes.

There are some things you can take apart, and some things you can’t. If you can’t or if it’s too much effort for not enough value, move on to another learning tool, but remain committed to your goal. In the light of fundamental flaws in how we think about security, privacy, and basic human welfare right now, seek something you’re proud and grateful to do. [There are some very worthy things happening in Boston right now.]

Subverting Social Bad Behavior with Community Service

Summary: personal aha…spend equal time on your community as you do on social media, and everyone will be better for it.

The Local Buffoonery of Garden Variety

When I woke, it was because of the shouting. That usually doesn’t happen in my neighborhood at two in the morning. I don’t mean like “hey, you forgot your beer on top of your car” kind of shouting, I mean the kind with curses and violence into the darkness of night. When I finally sat up to look down onto the street, between the fuzzy patches I saw a local taxi service driver furiously shaking his fist at something down the street yelling things.

As he used his mobile phone to call the cops, there was time to lite a…non-uniform cigarette…and pace around right in the middle of the blindest corner in town. Four more real cigarettes later and five flashing, silent police vehicles quickly swarmed what’s typically a peaceful daytime intersection that my apartment windows overlook. Two at a time, the tatted-up Ford Explorers sped away in the fisterly direction, leaving the final officer to take what I can only imagine was a confusing deposition and also a flashlight look-around to validate the driver’s story.

Today, Sunday, I drove downtown to ask the daytime taxi dispatcher what happened. I was expecting that I’d also have to stop up at the police station to get their official statement of what happened, but the guy at the desk knew the whole story and was happy enough to spill. Here it is.

After an overly complicated girlfriend-plus-other-friend pickup, some mentally imbalanced passenger, seeing a fare that surprised him as far too high, escalated an argument about the fare to an unexpected roundhouse punch to the driver’s head. That’s right, with two other people in the back, he temporarily disabled someone with the responsibility of driving them all somewhere on Eastern Point.

How doped up or insane does a passenger have to be to attack the driver? Why is this ragtag group of weirdos proceeding to somewhere on Eastern Point (very affluent)? Movie stupid, very upset, either or both. The world is really, truly crawling with crazy, fucked up people at all levels (especially in politics). And, like taxi drivers, sometimes you don’t have the economic luxury of pushing back on psychotic behavior when it comes your way because of what you do.

The Political Buffoonery of Friends and Neighbors

Assault is of course a crime…depending on who you are these days. It should be, it doesn’t work at very large scale in the commons where most of us live. But for some reason, everyone from the well-educated to the god-fearing seem to think that it’s open season on assaulting others who don’t share their beliefs. When it happens verbally on local social media (in particular, Facebook), I step back and ask, “what side of all of this do you want to be on?”

Take this guy I’d hope to call a friend, Jam. Jam is all kinds of good and crazy and well-intentioned. He runs a local blog, or maybe a cemetery where overly opinionated blog posts go to die, I don’t know at this point. Whatever he is, he’s complicated. Sadly, and rightly so, the current political climate has turned him into an-eye-for-an-eye asshole on social media. A counterpoint-liberalist, we’ll call him the Cook, recently said some things in response to Jam and other local liberals’ boycotting a local business for some insensitive things the conservative owner said. This is like Spanky and Our Gang vs. the Little Rascals type bullshit. “Not beef”, as some might call what this is.

This unwelcome display of reverse-perspective outreach sparked a knock-down, drag-out social media war between two individuals that are very reasonable when not provoked. But neither even saw what they were doing: focusing on the meta over the impact. Impact of their meta, more polarization. Opportunity cost of the meta over of useful action. Long-term impact of rejecting others’ views and position on their journey, a.k.a. karma. Acceptance that there is a shared journey. Acknowledgement that they may be wrong, no matter how much they think they’re right. That they are most certainly wrong if they think they’re the only one’s who can see something right. Complete subjectivity instead of focus on objective measures.

The result is that at least one of these parties is regretful and walking around hurt by it all. The worst thing is that I don’t think it’s my friend Jam. He still hasn’t worked his ego problems out before diving headlong into ‘other’ advocacy with women’s movement and anything else the overwhelmingly liberal-biased feeds feed him. All those things are good, but without love and respect, what good does it do for Jam to constantly interject himself?

It’s all buffoonery until we do something useful with others, not flashy or geeky or memorable or unusual. Not something that gets you a group photo with Captain Picard at a fancy inherited wealth house or the following to argue to against Trump multiple times a day instead of showing up to community roundtables about how to improve local education. Speaking from this experience, it was nice to be in a place where everyone practiced listening as much as they practiced having a spine and a heart. This is what I and others did yesterday from 3-5pm downtown. I don’t feel at all that way about the online shouting match Jam and the Cook participated in.

Don’t Let Nationalism Buffoonery Legitimize Local Buffoonery

You may think, “I’m so different than what’s going on politically right now, I need to speak out!” Please find more useful ways to argue with people over social media. Need solid reasons not to? How about that you won’t be permanently quoted in exquisite online conversational detail by an article like the one you’re reading now. How about, instead of counter-trolling, you could be sipping something nice right now. Fuck, anything but arguing with neighbors online.

Instead of escaping from the real world, think about how the way you view things affects those around you. How about that you don’t want your check-in with captured moments of friends and family to be perforated by “what’s trending” bullshit between town neighbors. Sure, share stories and articles that you’ve validated and make sense to you in various forums; but once an online conversation looks like it’s getting nasty, politely move along. Don’t let something as transparent and egotistical as “my blog swings 2,300 local votes” be your hood ornament. If people are being victimized, eject the violator and report their poor behavior.

In short, and to bring it full circle, don’t let a culture precipitated by a talentless, washed-up genital wart of a President and his cargo cult nationalist, supremacy-retrograding base suck you in to the human-capital machines that Jack Doorsey and Mark Zuckerberg built but now take it with their pants on from Russian mafia-state. Find me instead and we’ll identify something far more useful in our town to work on together. I’ve been collecting people’s challenges, many of them just take a little bit of help from others to overcome.

If you can’t be bothered to focus on useful activity over timespend on social media, at least try this: every minute you spend on social media this week, spend equal on something useful for the people who live around you. Can’t think of what that might be? I’ve got some ideas handy:

  • Donate supplies to a program that need it (this week, it was tampons)
  • Walk around your neighborhood (or just your block) and pick up trash
  • Clean up, repair something in, or just post pictures of a great little local park
  • Engage others to write about their local views over just your small clique
  • Prioritize and facilitate actionable community projects needing nothing more than hands and time to complete

When I see people not doing stuff like this, it’s usually the folks that maybe don’t deserve a seat at our community table. They like to bark, but don’t like to dig. They look influential, but are really inconsequential. They are simply taxpayers, not community members.