Principles Cut Both Ways

silver scales of justice with both sides empty and balanced

While I’ve become fully convinced Dave Ramsey is a fully-participating mechanism of the systemic class oppression he claims to help people escape, a line from “Total Money Makeover” has stuck with me.

“The good thing about principles is that they make life easy. I have heard it said that when someone bases his life on principle, 99 percent of his decisions are already made.”
Dave Ramsey

What’s not to love about that? You don’t need to decide if you’re going to deploy untested code — your department has principles around quality! I’d never starve the cat — I have principles against cruelty! I’d never allow sexual harassment in my workplace — that’s against my principles!

I don’t think it’s a hot take if I say that it’s not so easy. I also don’t have to think very hard to conjure up an example of conflicting principles. The issue, I think, is that how we rank our principles — their cascading priority — is what matters more than simply having principles.

This is normal — something is always going to be more important. The problem with that is much like implicit bias, we don’t really think about this ranking. Our brains just synthesize all the input can give us a snap decision that “Paying rent is more important than not abusing terms of service agreements.”

Managing Principles and Budgeting Money

I can’t tell you how many times I’ve gotten to the end of a month and wondered where the hell all my salary has gone. I’m usually pretty unhappy with what I find when I dig into the checkbook, too — impulse buys, random subscriptions, DoorDash orders several times a week. Absolutely none of it things I would have said is more important than paying down debt, yet that’s where my money went instead of the goal I supposedly value. This usually happens because I’m not actively deciding how to spend it, not holding up each decision to the light of my principles before keying in my card number.

Unless I make an active decision on each transaction (“I mean, yes, fish and chips would be nice for the third time this week, but each meal is also the cost of a minimum payment on the Discover card…”) then the money is essentially going to spend itself. And it’s going to do it in a way that has nothing to do with my stated principles.

It’s the same way with budgeting energy on a project. The number of times I’ve seen people get to the end of a card or sprint or even project and go “Oh yeah, I meant to fix that tech debt / try the new pattern / cross train that person and never got to it” is way bigger than zero. People (and yes, this means me too) tend to not even realize they’re letting their brain’s background processes make decisions like “We’re getting questions about how long this is taking so there’s no time to refactor that” or “Bob doesn’t even want to learn this part of the code so I won’t wait for him to be ready to pair.”

By the time we finish the card, we can see clearly how we did it in a way that we’re not proud of — the conscious thought reveals all the places we broke with principle. But by then it’s too late.

What to Do?

Decision making is like a muscle; it needs exercise. The implicit bias engine gives us a massive accelerator on decision making…but if we haven’t calibrated it correctly (and sometimes even when we have), then all it does is enable us to make the wrong decision faster. So we need to avoid relying on it, and that is a more difficult task than we realize.

It basically boils down to short-circuiting our ability to make snap decisions. We need to pause longer before picking a path.

Collaboration

One of the things I like (or hate, depending on the day) about pair programming is the extra step of discussing the next move with one’s partner. There’s a built-in slowdown that allows for things to move out of the background process and into the active cognitive thread. Plus, there’s a decent chance a partner hearing the solution is going to be more considering and critical of it — the number of times I’ve said to a pair partner (or had said to me) “But what about this” only to have them say “Oh, I didn’t think about it” is non-trivial.

Whether in a formal pair or a more informal “Let me run this by you” situation, the act of explaining your thoughts alone can provide clarity (rubber ducking, anyone?). Either you or a thoughtful teammate can remind you of goals that had been set or principles the team normed on, and point out what you just described doesn’t fit the bill.

Write it down

A line in a card about “Address tech debt around dependencies” is a pretty low-effort way to remember that little non-functional requirement. A big ol’ sticky note on the team wall or pinned in the Slack channel reminding everyone that we’re going to prioritize PR reviews is a good short term reminder.

This isn’t something that’s going to work indefinitely. There’s a famous parable in the Wendy’s world that advises us to “Clean the ketchup off the wall as soon as you see it, because next time you see it it’ll just look like part of the wall.” A sticky note in the “follow up” section of a team board has a shelf life of usefulness, and if you’re not actively engaging and refreshing them regularly then they’ll just become part of the decor.

A visual cue you’ll see somewhere long before the card or project is finished can be the nudge you need to review recent decisions and course correct before it’s too late.

Build a process

Whatever the details of it, you need to build a process for decision making that forces you to focus on the issue. It doesn’t need to be an hour long process, but if you can’t remember the last time you took 5 minutes to ponder something before reaching a verdict you might be letting your biases override your values.

A thing I used to do while running a department in a distribution center was make myself as a follow up question when asked for a decision. It usually wound up being more — the “ask a question” rule was to force me to break out of the kneejerk response.

Processor: “I think we should move the supplies to the end of bay, it’d be quicker to reup.”

Bad: “We don’t have time to do that right now.” Also bad: “Yeah, that could be good.”

Good: “How often are you having to reload supplies?” Also good: “Alright, but where?”

At least for me, discussion of an idea forces my thinking out of the automatic and into the conscious.

Bring it All Back Home

Everywhere I’ve enjoyed working for an extended period of time had a codified set of principles I could align with. Every manager I’ve thrived with has had an identifiable (if not clearly defined) set of principles they operated under. Principles are wonderful things, that both make life easier by giving you a scaffold to navigate challenges and signal your values to others.

But they only help if you use them. If you or your organization is allowing decisions inconsistent with your principles, that’s possibly a major warning sign — but I think it’s more likely a sign decisions are being made too quickly, without a process that aims to properly assess options.

Don’t make decisions on autopilot. Principles are useless if you’re not actively holding them up as a litmus test to see which path actually serves you best.

July 29, 2021 0

Yes, We Have No NaNoWriMo: An Exploration on Priority

A wooden hour glass with the sand in the bottom section in focus in a grayscale photo

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 2² 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.

December 20, 2020 0

A Software Version of NaNoWriMo

Every month in the United States has at least one official theme (I have no idea how these get set–is it Congress? Lobbying groups? Industry organizations that just spend enough money on ad campaigns? But I digress…) and November’s is National Novel Writing Month.

This includes an initiative called NaNoWriMo that started in 1999 (hello, “Holy crap I remember things from over 20 years ago” feels) to encourage writers to tell their story–and write 50k words of their novel during the 30 days of November.

But John, What the Hell Does Novel Writing Mania Have to do with Software?

Very, very little. At first glance anyway.

I tend to make tenuous, difficult-to-explain connections between concepts. Essentially what I’m working with here is motivational techniques, specifically two concepts: Big Hairy Audacious Goals and the Buddy System.

BHAG Connection

NaNoWriMo calls for writing 50,000 words of a novel in 30 days. That’s one of the biggest, hairiest, most audacious goals I can imagine. That’s 1,667 average words a day that advance a plot, develop characters, build a world in which those characters exist. That’s a significant amount of time, brain power, and creativity to apply consistently in a fairly short amount of time (with the looming American holiday season, no less).

I’ll paraphase Jim Collins in case you didn’t click thru the link above: if you want to do great things then you need to have big goals. Collins uses the moon landing as a key example of a BHAG–in 1960, John F. Kennedy said, “We’re going to put a man on the moon by 1970.” It was big enough to beg the question “HOW?!” which is exactly what gets the brightest minds in a room excited. It was also based in reality, since this is the nation fresh off the high of inventing the atom bomb, defeating Japan, and re-conquering western Europe all in the same 4 year period–conceivably, that same energy and ability can simply be redirected.

In case anyone missed the memo, it worked–NASA pulled the collective engineering genius, industrial capability, and economic power of the nation in line behind this goal and made it happen. Without the driving force of “We have ten years to do a massive thing from scratch” it’s conceivable delays and rationalizations could have made a moon landing impossible–look at how long it took to replace the Space Shuttle program without a compelling goal.

Buddy System

One of the major draws of NaNoWriMo I’ve observed is the community. People are pack animals–we tend to be at our best when surrounded by other people with the same goals. If anyone has been on “Author Twitter” during November can cite plenty of examples–people encouraging each other, talking up each other’s efforts, giving support when people hit their wall (because it’s all too easy for a BHAG to switch from motivational to a mental health trap). It’s just easier to do difficult things when you’re not the only one doing it.

You’ll see this (sort of) with Advent of Code. Particularly on teams that use the framework for team or skill building, or groups of peers who share solutions and challenges. The fact that there are people also making themselves tinker with code after working with code all day and are expecting to see your attempt is often what’s needed to power thru. The simple knowledge that you’re not in it alone (and that others know it too) can help one tap into a powerful reserve of motivation.

Applying the Concepts to a Side Project

A developer who is employed full time and has interests outside of software is sort of like NASA in 2011–yeah it would be nice to have this accomplishment, but it’s sort of taking most of our budget (energy) coordinating Soyuz trips with Russia (writing code to pay the rent).

This is 100% valid, for the record. Your side projects (or lack of them) have nothing to do with your value as a person, a developer, or an employee.

But say that because of who you are as a person, you’re frustrated by the lack of momentum on an idea you want to bring to life. Having that BHAG to move things forward significantly might be what motivates you to solve the problem of “How.” Finding a buddy or community working similarly big, hairy, and audacious goals can provide the support and accountability typically missing from these solo projects.

So when a friend of mine suggested I join in on NaNoWriMo with her this year, it planted the seed of “Yes, and what if I wrote software instead of a novel?”

So if not a Novel, then what’s the BHAG?

My goal is to deploy an MVP of a product I’ve had percolating for a couple months now. Shove it from the current v0.1 up to v1.0 and reevaluate.

Currently, I’m sitting on a non-trivial shell product:

One can create an account with a customized flow
One can see slightly different content whether they’re logged in or not
I have a CI/CD pipeline using Github Actions
I have a test environment in Azure

And that’s it. It started as an excuse to play with ASP.net Core and then I stalled once I reached those 4 milestones, little more than a Sprint Zero well done.

So what’s involved?

My product is yet another way to teach people how to write software (because there are plenty of resources for learning to code–but turning code into software is another sport altogether). I plan to develop my own platform (because writing code I want to write is different from code I’m paid to write) as well as the content.

I have 31 initial stories across 9 features–but there’s several spikes that I expect will lead to additional stories. That’s already more than 1 story per day–and based on my “Sprint Zero Point 2” work this past week, that’s 100% not realistic.

So Why Do It?

Because I’m pragmatic. And agile. I feel goals–even BHAGs–are guidelines, landmarks to track to gauge progress and priority. They’re a thing to aid in decision making. If I get to Thanksgiving and I’m looking at 40 cards in the “Done” column, I’ve learned things. If I’m instead looking at 4 cards, I’ve also learned things.

And in either case (or the more likely middle ground case) I’m still closer to the ultimate goal than if I did nothing.

November 1, 2020 1

The Almighty Card Board

A Trello list of cards showing several color coded tasks

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:

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:

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

My second effort will focus on:

Setup Travis-CI to build and test my solution
Write about setting up Travis
Write some tests against the web project’s UI
Get them to run in Travis
Write a post about UI tests
Wire the web project to the code library
Update UI tests to reflect the dynamic logic
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…

July 28, 2019 0

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.

July 21, 2019 1