How I Stopped Worrying and Learned to Love the Bang

I recently stopped cold while writing a ReactJS component and experienced a very brief (albeit intense) existential crisis. I had just, without giving it excessive thought, used not just a ternary expression to determine what the component would render, but I also used a bang in my logical test.

First: My Beef With Ternaries

I learned early in my code journey about the value of legible code, of chasing the paradigm of self-documenting code, of explicitly indicating one’s intentions with a minimum of mental friction. This is largely why I resist writing ternary operations wherever possible, thinking that an item like this

var result = input > BASELINE ? "Input is above baseline" : input < BASELINE ? "Input is below baseline" : "Input matches baseline";

is a difficult-to-read unclear mess; whereas

var result = string.Empty;

if (input > BASELINE)
{
    result = "Input is above baseline";
}
else if (input < BASELINE)
{
    result = "Input is below baseline";
}
else
{
    result = "Input matches baseline";
}

puts practically zero friction on the eyeballs and takes nearly zero effort to understand.

I can understand the desire to write as few lines of code as possible, for a lot of reasons we don’t have space to get into just now. But I don’t feel that brevity was a good enough reason to make something more difficult to read. Many pair partners can attest I have a tendency to start with a classic IF-ELSE block and resist refactoring it into something more brief.

Enter the “Bang”

I might have a strong distaste for ternaries, but I absolutely despise using bangs. The fact I feel compelled to take a moment and define what the hell it is for the less technical reader seems to summarize my issue with it–it’s an overly complex tool.

A “bang,” is simply an exclamation mark (“!”). In most (all?) programming languages, we use it to mean “Take the opposite of this bool (true/false) value.”

For instance, if I have a bool variable “isDarkMode” that equals TRUE, then “!isDarkMode” means FALSE.

Nice and confusing, yes? Thanks; I hate it. To be fair, I have seen cases where using a bang is the most elegant (or least messy) way to get what we want…but more often, I’ve found it to be a sign of lazy naming, poor coordination across application layers, or someone trying to be super clever. It just smells.

// Dark Mode is enabled when the UI element isn't toggled because it's wired backwards
var isDarkMode = !uiToggle.IsToggled;

if (!isDarkMode)
{
    // set everything to light mode styles
}
else
{
    // set everything to dark mode styles
}

You might think this is contrived, but I’ve looked at similar blocks of production code more than twice, going “Why does this make my skin crawl.” A couple quick refactors (like inverting the IF and ELSE to get rid of the need for the bang or renaming the variable so we can use the <uiToggle> the way it was written) will restore sanity…but suffice to say when I see “bang” I say “Oh dear.”

You May Ask, “What Changed?” I’ll Tell You…

I essentially learned to code in C#, and then spent the first years of my career primarily in the back end of .NET Framework applications. I relish the sense of order that comes with strongly typed objects backed by interfaces. Knowing I can extend these stable items whenever I needed new behavior (and knew they’d behave the same way over and over, or throw an exception trying).

More recently I’ve been adding functionality to a React web app (as you may have gathered from my opening paragraph). I’ll own it–JavaScript in general, and ReactJS in particular, were technologies that baffled me as I tried to become fluent in C#. The differences between a strongly typed language and the chaos of JS were bad enough–but React leverages the extreme flexibility of JS in ways I couldn’t comprehend.

For instance, the fact that when using a child component you can pass in one, some, all, or none of the properties defined or used in that child component without expressly providing overloads for the component. Try that in C# and see how fast your app blows up.

// Renders an empty view in light mode
<ChildComponent />

// Displays the list data in light mode, but does not render edit options because no user
<ChildComponent
  dataList={list}
  />

// Displays the list data with all options, in dark mode
<ChildComponent
  dataList={list}
  userId={user.id}
  darkMode
  />

The magic, and my existential crisis, happen inside the child component’s Render() function, thanks to how JavaScript handles resolving objects.

render() {
  const { dataList, userId, darkMode } = this.props;

  if (darkMode) {
    setDarkModeClassNames();
  }

  return (
    <React.Fragment>
      { !dataList
        ? // render empty display
        : // render the list
      }

      { userId &&
        // render the edit/add options
      }
    </React.Fragment>
  );
}

Because JS nor React will balk if any of those three properties are unassigned, we can (and should) take different actions depending on if there’s actually an object attached to that variable. React makes this easy enough with their conditional in-line rendering.

What we see here inside the logical operators is shorthand for “Is this defined?” and when we apply the bang “Is this NOT defined?” It’s checking both that the variable has been defined, and that it has been defined in a usable way (ie, dataList isn’t null). We could do this manually and explicitly…but that’s not good, idiomatic, or smart JavaScript. It’d be like writing one’s own “string.IsNullOrEmpty()” method instead of using the built in C# method.

You’ll see I open my first ternary with a bang (aren’t you glad you’re not paying for this content??). I did this because I felt, in this case, it IS the most explicit approach. I wanted to indicate what the next person in the file should pay the most attention to–the component cares if the listData is missing. We could invert this ternary and get the same result…but, I wanted to emphasize “The weird, early-return style behavior happens when there’s no list data.”

And yes. I’m using a ternary here, two if we count the neat short circuit with the userId. For one thing, I can break it up over several lines for clarity. For another, it would be significantly more work to replicate this behavior in a different pattern. It makes sense, and (based on the existing examples in the code base plus all the reading I did) it’s idiomatic React.

TL;DR…

I had a major polyglot growth moment. I embraced the features of a language that just wouldn’t fly in my “home” tech stack, and I added a whole mess of tools to my kit to use and reference going forward. What is nonsense in a typed language is totally fine in an untyped one, and that’s okay.

Yes, We Have No NaNoWriMo: An Exploration on Priority

At this point it may be obvious, but the whole software-version-NaNoWriMo didn’t get out of the “add cards to a Github project” phase. What might not be so obvious is this totally okay. Preferred, even, though I know that’s going to sound counter-intuitive (or even like a cop-out).

So let’s talk a bit about Priority.

Merriam-Webster defines “priority” in part as

“The quality or state of being prior” or “Superiority in rank, position, or privilege”

Merriam-Webster.com

That conjures up images of “priority boarding” or “priority projects” or “making that task a priority.” We’re moving or designating something to the head of the line. Something with or or being given priority is more important than other things, for whatever reason.

“But John–does that mean your BHAG wasn’t important enough to get to the top of your priority list?”

me, impersonating the reader

Hold on just a minute — I’ve got another definition to cover that should address this.

This time, it’s a definition for “economics.”

“Economics is the art of satisfying unlimited wants with limited resources.”

A CSCC Economics Instructor Whose Name I Wish I Could Find

While economics generally uses capital, material, labor, land, and similar such as “resources,” I think of personal resources. Time is a resource. Rest (personal energy level) is a resource. Brain power (cognitive ability) is a resource. And they are absolutely finite, and absolutely limited.

As much as I might wish to, I cannot simply make myself have more energy in a day than I do. I can maximize it with good sleep hygiene, diet, and exercise–but when I’m tired, I’m tired. I only have a certain amount of cognitive cycles in a day. I can be efficient by writing code in small (test-driven) bite-sized pieces, and protect myself from burning through them all by taking frequent breaks–but I’m going to hit a point where it takes me too long to figure out whether 2+2 and 22 are equivalent. There’s only 24 hours in each day–I can be efficient with them, but at some point the the day is going to end regardless of my to-do list.

This means I have to apply economics to my life–I have to apply the lens of Priority.

When I think of Priority, it IS about what’s important, but there’s more to it. What simply can’t go undone lends something a higher Priority score. But then again, if something will increase my personal resource pool, it might gain Priority even though there’s no explicit need to do it sooner. Will something shrink my resource pool, and can I afford to that that hit right now? It’s a loose ranking of “How much this thing helps me be my best self.”

This isn’t a new concept, doing the truly important things first. Franklin Covey talks about putting big rocks a jar; my therapist talks about prioritizing self-care. It’s a pretty fundamental concept in time management–you do what’s most important first, and the rest falls by the wayside.

While most of us are good at this within individual, well-defined buckets–we’re consistently able to put an e-mail to the client ahead of watering our desk plant, putting sleep ahead of being at the bar till close on Tuesday, remembering our spouse’s birthday and celebrating it–sometimes we don’t always apply Priority to those buckets in relation to each other. Or worse, we place items in the wrong bucket–letting us allocate resources incorrectly, leaving us unbalanced and weakened.

All of this to say…

The issue with my little NoNaWriMo challenge is it’s easy to mis-bucket. It’s a project I expressly create for my personal time; a side project. This implies it should have been easy to work in–just watch less TV, or play fewer video games, or cut out that movie with the wife. But the reality of when it needs to happen does not change what bucket of personal resources is allocated to the effort. For all useful intents and purposes, a software developer’s side projects are part of their professional life. Let me say this again, for the young devs in the back who need an answer in some tech bro’s interview:

A software professional’s side projects are non-compensated professional activities, typically undertaken in time that would otherwise be spent on self-care.

This means the personal resources I have available for these projects, no matter how big or hairy, come from the same bucket as my day job. If my day job has eaten up all or more of it’s allotted brain cycles, there are none left for the side project. If I feel drained after pouring hours of energy into sprint planning and code review discussions, there is no more energy leftover for the side project. If I worked overtime to get a functionality in ahead of a deadline, then there is drastically less time available for side projects (because without one’s other activities, one is worthless). If re-engineering a module to satisfy contradicting new and legacy requirements gives me a headache by 2pm, there’s no way there’s any brain power left in the tank for that side project.

Alternately, even if work was easy and I have plenty of excess resources: if I’ve slept poorly and need to prioritize keeping my evenings low key, there’s no room for the side project. If my spouse had a bad day with work and needs extra support, there’s no time or energy for the side project. If therapy dug up some sticky stuff I need to process, there’s no ability to work on the side project. Because balance means nurturing yourself and your support network, not just your professional life.

TL/DR:

Nearly every day in November, applying this Priority lens to my left showed me one of two things: either I’d expended everything allocated for work at the day job, or I’d been presented with an opportunity to invest into myself or my personal relationships. I refuse to view this as a problem.

The Almighty Card Board

If you’re a professional developer, and your team isn’t using a ticket system, you’re probably familiar with card boards. You may even be a Trello wizard–I personally have spent more time in Microsoft’s Team Foundation (now called Azure DevOps), but it’s the same idea. A way to track what needs to be done and how long it’s taking.

Since this is a (relatively) simple one-off project, I just threw together a Trello board. Here’s the 800-mile-view:

A view of a Trello cardboard with Backlog, Current Effort, In Progress, and Done lists

My backlog is the total sum of what I want to get done/cover in my post series. I have code items (labeled in orange), infrastructure items (labeled in green), and posts to write (labeled in yellow). I have them roughly grouped in order by things I want to do for a specific post.

Current Effort is what might be called a sprint–it’s the group of cards I think are obtainable to get done in the next week or two. To continue my trip analogy this is just the next leg of the trip–maybe how much ground I want to cover before stopping for dinner. It would be the point where I would feel comfortable putting in a pull request, a point where if need be I could say “I have to put this aside for three months” and be able to pick it up as a complete module of the larger project. The acceptance criteria for each “effort” is to have one or more blog posts scheduled.

In Prog is just that–in progress. Stuff that I’m still working on, since I anticipate doing little bits throughout the week.

Done should be another self-explanatory item. It’s all cards I’ve completed–not just during one effort, but over the course of the whole project.


My first step was to fill the backlog. Everything I needed. For instance, I knew I needed a simple code library to provide some sort of functionality. I also knew there’d need to be some sort of web project that can display that functionality…but I wouldn’t need to link them together yet in order to write a blog post about them, or to get the solution to build in a CI system like Travis.

I decided my first effort would look like this:

  1. Write about this plan, and my high-level thoughts on planning solo projects
  2. Create the Trello board to map the whole thing
  3. Write about the Trello board and my planning process
  4. Setup a simple code library I could test in a CI system
  5. Setup a simple web project just to have it ready
  6. Write about the code skeleton

My second effort will focus on:

  1. Setup Travis-CI to build and test my solution
  2. Write about setting up Travis
  3. Write some tests against the web project’s UI
  4. Get them to run in Travis
  5. Write a post about UI tests
  6. Wire the web project to the code library
  7. Update UI tests to reflect the dynamic logic
  8. Write about wiring up the two

After that, I’m not sure exactly. Logically, deploying the program is the next step, but I’m not going to think that far ahead. Sticking with the road trip mentality, I know where I’m going tonight, I know roughly where I’m going to be the night after that…anything further isn’t super useful to plot in detail. I just don’t know what will happen.

Honestly, I’m already second guessing how big that second effort looks. I’m a big fan of bite size pieces. But, since I don’t have a better idea and all of that is grouped logically together, I’m just going to roll with it until a better idea presents itself.

I’ll repeat this process till I get all the backlog cleared. If something needs to get added to the backlog, or needs to go back to the backlog, I’ll do it. If I learn after the next effort that 3 posts is way too much to try and fit into a week, I’ll trim the next one to account for it.

It feels pretty Agile to me, but as a millennial I hate to put labels on things, y’know…

Q: How Do You Walk From Portland, OR to Portland, ME?

A: One step at a time.

One of the major challenges I had (and still have, if we’re being honest) is looking at a project I want to do and actually delivering it as a solo dev. As time has gone on, I’ve learned that’s not exactly a problem exclusive to solo devs. One of the things that I have really appreciate at Pillar/Industry X.0 is how we approach this problem…and some of it really translates well to hobby code and side projects.

There are two key points I want to harp on:

  • Know where you’re going (what your desired end result is)
  • Do only the next thing (focus on what makes sense at the time)
Know Where You’re Going

My personal problem with a lot of side projects is I get an idea, and I start writing code for it. I don’t think about what the end result is going to be, usually telling myself “Don’t get too far ahead of yourself, just flesh it out a bit and it will become clear as you go along.” While I think this is a pretty decent way to write a novel, I’ve come to realize it’s a terrible way to write software.

There is a not-so-subtle difference between planning too much and planning too little. There’s no real benefit in planning out every single thing in advance, from the size and color of your standard buttons to how to promote your new app. But the general idea–web app or mobile? Is this going to live in Azure or AWS or Heroku or what? Am I using GitHub or BitBucket? Should I be continuously deploying this?–helps guide the architecture, the tech stack, and helps define the tasks.

Writing the code is important (sort of the point), and is broken up in it’s own way. But when does it make sense to setup a build pipeline? The repository? Do I need a production environment? When can I actually see changes when I deploy them, anyway? By keeping these questions in mind, by seeing a bigger picture than just features in the code, it helps guide the overall workflow.

Do Only the Next Thing

Having those tasks ranked and in rough chronological order helps you stay focused. Now you can say, “Self, we are going to test drive this feature here. And when it’s done? We’ll setup a build pipeline so it’ll merge into master on it’s own.” Once that pipeline is working, “Self, now we’ll add this other feature here, because when it’s done we can add it to a UI project!”

By modularizing the tasks, you’ll avoid the trap I always seemed to fall into–“I have a web app with no logic behind it and deploying it is a nightmare” or “This code library I spent a month on is useless till I get it plugged into something and I am just too tired to figure out what to do now.” Being able to focus on checking things off a list is satisfying and keeps things moving, especially when you’re navigating a full time day job.

You know you need to cross the country to get from one Portland to the other, but if you focus on that you’ll never make it. You need to focus on getting to the next stop, rather than the whole trip.

The Great Pipeline Post Project

I had this great idea to blog about setting up a CI/CD pipeline, both for much-needed practice and to relay some lessons learned. Spoiler alert: this is a much bigger deal than it seems at first glance. I sat down to get started and quickly got overwhelmed by the sheer volume of things to work through, especially as they occurred to me randomly, while I was sitting in front of Visual Studio.

That’s where this post came from. What if, instead of just breaking down how to setup a pipeline and all the steps under that umbrella, I started with how I planned this mini project? If my target audience would benefit from seeing all the pieces of CI/CD tied together it’s likely they’d benefit from seeing the pre-work too.

Over the next few posts we’ll start by exploring the planning that goes into standing up a new project and move on into the actual work needed. My goal, the whole time, will be to keep it on track and demonstrate how the joint efforts of knowing the plan and doing on step at a time keep things moving at a steady pace.

Configuration is the Real Magic

I talk about writing software being like magic. It’s how I view the craft in a lot of ways–using arcane words and phrases combined with strange tools to conjure amazing things out of a series of 1’s and 0’s on a circuit board. But when I describe my ultimate career goal as “being a wizard” I mean something, or someone, very specific.

I’m not talking David Copperfield or Penn and Teller. They are very skilled magicians, not wizards. That sort of magic is based on memorizing an illusion, of doing a thing in a certain way because of the reaction you know you’ll elicit. One does a very specific thing, or specific set of things, in a well organized way, over and over and while it gets more polished with practice, it will always be the same.

The words “programming is magic” conjure up Gandalf for me, from the Lord of the Rings universe. For the majority of those adventures, it wasn’t actually magic that made Gandalf the go-to guy–it was never “Gandalf has a spell for that.” What made Gandalf the truly formidable foe and an invaluable ally was the fact he knew things. He understood the old lore, the behavior of people and animals, how the elements of the world fit together and how they could either help or hinder a particular goal.

Gandalf knew the configuration of Middle Earth. Maybe not the *exact* configuration for every situation, but he knew what was missing, or what was the blocker. His magic was always a tool to divine knowledge or to force something into place, to adjust the configuration of a situation. Never magic for the sake of magic, happening in isolation.

“Gandalf knew the configuration of Middle Earth.”

Just like the veteran programmer on the team who always seems able to spot the problem

Continue reading “Configuration is the Real Magic”

Blog at WordPress.com.

Up ↑