Category: Monocategorized

I write this blog for many reasons. One of my goals is to help people learn important, hard-fought lessons without experiencing some of my pain and suffering.

According to Nvidia’s CEO, there are also times when it is important to learn those things yourself.

So when my oldest son Carson started fiddle-faddling around with no-code platforms and told me that no-code application development is the future of software development, I nodded, I smiled, and I did nothing.

I will not bother linking to the random no-code platform that captured his enthusiasm. Instead, I will smugly link you to his public Instagram page. It is even there in the name.

Over the next six months, I listened intently to him describing his no-code journey with some amount of nervousness and fear. It is one thing to hear his opinion on the future of software development and yet another to take prescriptive action and correct him.

Fast-forward two years, and all of that “doing nothing” has paid off. He has started building his APIs and platforms in Python and is running a growing business.

Somewhere along the way of coaching and teaching people, I have learned that it is important for a teacher to know when not to teach.

This is a serious problem for today’s staff engineers and architects. Many talented software developers have gone through that zero-to-one transition for creating software platforms. Many more have learned how to scale up through growth measured in thousands of percent from their current user base.

Their problem is that they need all their lead and senior software engineers to go through the same exercises to learn the necessary patterns to operate at a higher level.

For this to happen, you must let your teams propose systems that might not be ideal or forward-thinking. You can softly give them feedback that there are missing pieces and give them some gentle and subtle clues about bridging the gaps to the solution they will eventually need.

Far too many engineering leaders will do all that work themselves and lose a valuable teaching opportunity. Maybe there is some scarcity mindset or fear involved, or it is simply a lack of forethought on their part, and not in a bad way because they have never needed or wanted to grow one or more engineers to a peer level.

I guess this is just a restatement of the old saying, “You can lead a horse to water, but you cannot make them drink.”

Please make sure your mentees (and yes, your children, too, although technically, this is not a parenting blog) have enough opportunities to learn valuable lessons on their own sometimes.

When the opportunity arises, and they are either successful or not, let them know that this was an intentional opportunity and that they are wiser for it.

The explicit statement afterward is important for creating psychological safety. If your teams know they have some opportunities to grow, including some risk of failure, they will be far more impactful than a team that slips task management tickets while keeping on a narrow track.

Have you ever gone to the internet to search for something you needed to buy? Once, an overwhelming sense of professional obligation to own all of my work software inspired me to obtain a Visio license. Rather than going to Microsoft, which may have been the most obvious thing to do, I went to Google and typed “Visio.” This was in an era of significantly more aggressive adversarial advertising. There is some kind of sick trust between Steve Ballmer and the average Microsoft customer that inspired them not to spend money on buying Google ads. While I am a gigantic fan of Microsoft developer products, I was not so in love with the Visio brand that I was willing to completely ignore the product offers from Microsoft Office competitors. SmartDraw was at the top of the sponsored links at the time, and it looked like they were ready to party.

This is how I became one of their customers. I was seduced by the novelty that Microsoft was so flagrantly uninterested in my business that they did not wish to pay to stay on top of the Google advertising spender leaderboards. I felt like I was some super-smart bargain hunter for the simple act of a mouse click.

I have about six or seven very good years of architecture diagrams from my steady relationship with SmartDraw. I think the success of their clever marketing began to cause problems. They began to iterate on SmartDraw like professional arborists “iterate” on the plants that are “under their dutiful care.”

There was a particular release where they stopped maintaining feature parity with Visio.

I don’t know what to say about what happened next. A breakup? A funeral?

SmartDraw and I were no longer seeing each other, that is for certain. After so many wonderful years, why they decided to make this change is unclear. I imagine I was not the only person who stopped using their product that day.

This is probably the first time I realized how important advertising or marketing your product is. I was a product-first “if you build it, they will come” entrepreneur. Maybe parts of me still are. Not the Derfdice part, though. I built it, and nobody came. There was a mild collision there between my aspirational view of the hardcore tabletop game dungeon master and the arrival of LLM technology. It was quite humbling to get zero million customers. Fortunately, I broke even on the product in other places and other ways.

This is a short one today. If you ever want to throw some money at a company for a product, seeing who else wants your money more is worth it. I am firmly back together with Visio again if anyone is keeping score. I have found additional replacement products over the years. Oddly, the next best example is also a Microsoft product. I was an Intellimouse lover for years, and now I find myself besties with the Razer Deathadder.

I would love to hear some stories of “surch…” Where you go to the internet to find a product and purchase something better or cheaper.

See you all next week!

Before you think that my blog subject is some kind of boop boop lazors noise from a space movie, I want to point out that it is my own cleverness in writing “three-in-a-row.” Yes, I am fine. No, I am not sorry. I am not going to blink twice, I am not in danger.

Today, I want to talk about three-in-a-row. I have selfish reasons to avoid calling it by its proper name. If you have ever gone past the “let’s send John a resume” phase of a professional relationship with me, you would be on the receiving end of an obnoxious IYKYK. You can Google that if it confuses you.

Why are we talking about three-in-a-row, aka tic to the tac to the toe?

Because when other people ask me, “Hey John, how do you learn a new programming language?” This is the first program I write.

The first thing I do is build a three-in-a-row game.

I do not have an unusual affection for three-in-a-row. Using the popular minimax algorithm correctly would make an unbeatable puzzle that fails to define a game. I love implementing three-in-a-row as the first thing I build in a language because it has a few abstractions that are good ways to flex your ability to use a new programming language.

Multi-dimensional arrays: You should store the board in an array of [x] and [y] values.

Some business logic: Deciding where an AI player should make a move is a fun little exercise.

Inputs and outputs: Hello world is nice but you are just printing things. Making a full command line (or graphical) game requires more mastery. Are you processing clicks? Are you converting input to numbers? Is your input good? Are the moves valid?

The classes: You can put the board and the player into objects, even with a little inheritance from GenericPlayer to AIPlayer and PersonPlayer.

When I do this, I generally do not use minimax. I like to make a reasonably simple set of functions that iterate over the board, reusing a common function to see if a row is complete or is about to be complete.

I also added a random chance for the AI to make a useless move to ensure the game does not always end in a hideous tie.

So here is a little pseudocode logic for you on the AI’s turn.

if( MakeWinningMove() == FALSE ) {

  if( MakeDefensiveMove() == FALSE ) {

    MakeRandomMove( );

  }

}

This seems pretty straightforward. Try to win the game. If you cannot win the game, try not to lose the game. If neither of those are serious issues, then make some random move and be done with it.

In the function MakeWinningMove(), for example:

We will make a list or set of all the empty pieces.

We will loop over this list and temporarily add an AIPiece.

Does this give us three AIPieces in a row?

Return TRUE!

Otherwise, remove the AIPiece from this location and restart the loop with the next value.

I reuse an iterator function that checks horizontal, diagonal, vertical, and reverse diagonal lines in a 1 to N loop. I think it is important to avoid magic numbers. Suppose someone sends me an implementation of a three-in-a-row game. I look for a variable or constant declaration of BoardSize set to 3 and almost immediately increment it to 4 just to see what happens. Sometimes, it works, and sometimes, it doesn’t.

The logic for MakeDefensiveMove (and MakeRandomMove) is largely the same. Avoiding DRY (Don’t Repeat Yourself) Violations is a good practice.

By the way, this is not the best implementation for three-in-a-row. It is fast and easy to test and does not crush players’ souls by being totally unwinnable.

Quite a bit of this post is about hints for what I look for when conducting software code screens. I was trying not to say that in easily searchable terms for future engineering candidates. I have made this obscure enough that the bonus points for anyone improving their code submissions after finding this article will be worth it.
So now you know how I learn new programming languages. I try to do this frequently enough to stay a lifelong learner and I think this is better “gud brain” exercise for you than tugging at the chunks of wood and metal that you can buy from Amazon at this affiliated link right here. See you next week!

I spent some time looking for engineering coaches for others a few years ago. While conducting early interviews to understand what they do and how they measure their success, I got a lot of puzzled looks from potential coaches. Most of them measure their success by the size of the fire they have put out via their coaching, and almost none of them were being asked to coach people where there were no issues.

I was equally puzzled by this. Having coached many people on my team and a few outside of my team, surely the executive teams at most companies understand that you want to invest universally in improving the outcomes of one of your biggest cost centers. I am wearing my shocked Pikachu face right now. I was going to see if I could find some Amazon merch to pimp for this, but all of the shocked Pikachu merchandise there is super sus. Or is it suss? I cannot keep up.

It turns out that companies spend on coaching when their engineering organizations or products are on fire. It is far easier to get the blessings of the bean counters for reacting to a problem than it is to invest in proactive coaching that might keep you out of trouble in the first place.

Why is this true? It seems that there should be more appetite for proactive coaching rather than just reactive coaching in much the same way that people say, “An ounce of prevention is worth a pound of cure.”

I recently attended a CTO talk in OC. The speaker blew me away by describing how they upgraded their internal data platform using Databricks. At the end of the talk, I asked her where she had learned the soft skills needed to get approval for this project. She attributed it to her career coach, which she paid for alone.

I decided to ask another question at the end of this talk, similar to one I asked during an engineering presentation at GDC in March. I asked the audience how many people have coaches or mentors. In both cases, far too few people put up their hands.

I was disturbed by that. Many people blindly trust their managers to look out for their careers. I have had engineering leaders with incredibly scarce mindsets at some companies where I have worked. It is dangerous to trust your own potentially abundant success in the hands of a zero-sum game thinker. Unfortunately, I am speaking from experience here. The vast majority of times I have had an engineer as my boss, they were generally very poor leaders. Early in my career, I confronted some of them with their poor thinking (I was not thinking in terms of abundance and scarcity until at least 2012). Later in my career, I would gently suggest abundant alternatives to find what justifications they claimed to adhere to their course of action. In either case, I seldom convinced anyone to adjust their thinking.

Coaching people on your teams is possible if you are diligent about it. You just have to be very mindful about cannibalizing your coaching in favor of business outcomes. As a coach to people I manage, I often have to include caveats to ensure they know there is sometimes a lack of alignment between these two things. Sometimes that lack of alignment is not subtle.

If your boss is tunneling too much into their own work outcomes and objectives to be an effective coach for you, it may be time to reconsider where you work. Many companies offer lifelong learner paths that include coaching resources and learning opportunities.

Alternatively, see if your company will pay for an external coach to help improve your outcomes. It does not hurt to ask. If they say no, you might be able to find a coach willing to give you a “stingy company” discount that takes into account that your personal budget for self-improvement is smaller than the line items in the L&D budget for the company.

Give me a shout if you think that is interesting. I coach people myself, and I am connected to about half a dozen other coaches right now who have tremendous engineering leadership experience and can help you ensure you are maximizing your career potential.

This is enough of a sales pitch that I do not wish to sully it with an Amazon Affiliate link.

See you all next week!

I make a point of trying to unplug on Saturdays. Part of this ritual includes getting my steps in—of which I try to get twenty thousand while I am at it. At least sixteen thousand of them come from a single hiking exercise where I walk to a nearby regional park and walk in a loop on some rather rattle-snakey trails before walking home.

Imagine my surprise when I spotted an interesting-looking fence post on the way to the park that appeared much shorter than its peers. My photograph does not do it justice. The exciting part about this repair job on the fence is the blog post opportunity it created for me.

This picture lets me ask you: How do you decide how much time and resources to spend fixing issues in production?

In an ideal world, you would want to replace this shortened pole completely. That means you would need to dig up the pole, transport a replacement pole to this location which is nearly one hundred yards away from a nearby parking lot or road, and then somehow drive it successfully into the ground.

Two of these three steps involve some kind of machinery and/or transportation. You will need to bring the post to a nearby road and then have a machine of some kind that will drive it into the ground. You might convince someone to carry it from the back of a pickup truck to that location while you are at it. This is the work of two or three people, one large transport, and one pile-driver machine. If you were looking at the costs of this enterprise, you are likely well into the single digits of thousands of dollars now.

The alternative is for one person with a chainsaw and a power drill to cut a new groove further down the post and bore a hole into it to attach the bolt. This is likely about an hour of work and probably the work of one person with a small bag of tools.

It does not look perfect, and almost nobody will care. It will do the job the previous fence did.

One of the roles of engineering leadership is to decide whether to do the patch job on a pole with a quick fix like this or a deeper refactor that costs more time and resources to solve the issue more completely. Most of the time, the deeper fix to an issue like this is best done after thinking about it more deeply and probably modifying two or three other problems simultaneously.

I am quite pleased with myself. A passing observation on my extensive weekly hike purchased a week-long backlog extension for my blog. I have a reasonably deep queue of subjects to entertain you all, and every time I can extend it, I feel like I have accomplished something.
I feel like celebrating. What better way to celebrate than to order a delicious boxed set of Tortuga Rum Cakes? Please click on this affiliate link and purchase this amazing assembly of delectable treats to participate in the festivities!

As a parent, the number one question I get asked by other parents is, “How do I get my kids to have a job like you have?” It is a great question. I have a horrible answer that scares most of them away. “You have to love mathematics and problem-solving.” Modern society has instilled a fear and loathing for mathematics and hard work in our children through popular media. I believe these are essential cornerstones to a successful knowledge worker career. While I do not love his books much, Andrew Friedman gets this much right:

“In China today, Bill Gates is Britney Spears. In America today, Britney Spears is Britney Spears — and this is our problem.”

I mean, the dancing is okay, and the music to me is kinda mid, but you get the idea, right?

So, how do you embark on a career as a software professional?

To bastardize another popular quote, this time from the movies:

“Show me the source code!”

And I put the word source code, where it used to say money.

Now that I have bombarded you with not just one but two trite internet quotes, I will proceed to dispense with my own wisdom.

There are four paths to a career in software development. They have varying costs, take varying time, and have varying degrees of success.

The first and most traditional way to get into software development is to take a four-year college degree program specializing in computer science or computer engineering. It takes four years and costs tens of thousands of dollars. I was fortunate to get into a co-operative education program where I could work between semesters and get paid. This enabled me to get through my degree with low student debt. It is harder to do this now than it was when I went to school. The costs are accelerating, and the barrier to getting accepted into a four-year program has never been higher. I am not certain that if I were just finishing high school today I would even get into the University of Waterloo!

The second way is to take a boot camp program. You can go to many places to get a four- to twenty-week boot camp. This takes less time than a college degree and is less expensive. I believe most of these are less than the cost of one year of college. There are remote boot camps like the Chegg Skills program and local businesses that specialize in this, like LearningFuze. I have met with candidates from both programs and found they have reasonable day-to-day skills for a junior software developer. I have hired a few people from these programs as well.

The third way is the hardest for most people. You can sit down and start learning it on your own. There are a variety of tools and videos on the Internet to help you become a software developer. I have worked with half a dozen self-taught software developers, two or three of whom are among the best software developers I have ever worked with. I have a limited amount of advice on what resources to use to become a self-taught software developer; it has varied over the years. All the people had high innate math skills and intense curiosity and grit. This takes between six weeks and six years, depending on the individual.

The fourth way to become a software developer is the one I have seen the least. You can find an existing software developer and attempt to become an apprentice. I am mentioning this because I have attempted to find a software apprentice a few times without success. I have met many people who expressed a strong interest in pursuing a career in software development, and when presented with an option to help get them there from here, they wrote more excuses than lines of code. A friend of mine is attempting this with one of his friends right now. This is on par with the time frame for a boot camp but without the cost. It requires knowing someone who has the skills as a senior software developer committed to helping you get there from here. I will update you all when I hear back from my friend on how this went.

This is a short post today, and hopefully a good one. Thank you for being patient. I know this blog post generally comes out earlier in the week. We have back-to-school stuff happening, heat waves, and of course, World of Warcraft: The War Within all happening at once this month and I have been battling with time on all three fronts.

That being said, if you know any late-night West Coast Havoc Demon Hunters looking for a raid guild, hit me up. Our raid team needs one.

If you have been sentenced to a career in technology for at least two decades, you might observe that there are repeatable patterns when The Next Big Thing arrives. I will not give you links to those stupid graphs for each investment wave. Google “VC Hype Cycle” if you have no idea what I am talking about. If you will not click my affiliate links to participate in The Great Amazonian Nickel Heist, I will not give you other free-er links to click on. You have only yourselves to blame.

Now that I have churned some number of shocked and appalled people from my readership, let’s get back to the nitty and the gritty.

I have been telling people that industrial memory is seven years. That is the length of time for the average boom-bust cycle in tech. I am still here because the overall trend line for this is still positive. The busts drop us down slightly less each time, and we continue to do slightly better every time. I guess that makes me a boomer? Probably in more ways than one.

In games, the boom-bust cycle also has some very interesting side effects. The first is the role of portfolio management. Every publisher has a set number of titles they like to manage. As we enter the boom cycle, these people tend to get super excited about publishing, and they start to act irrationally—somehow believing that this will help increase their job security. I will give you a spoiler here: This part of the pattern of behavior does not increase anyone’s job security.

I have seen publishers comfortable with ten nice titles in their portfolio start taking moonshots as the market heats up. It is not uncommon for publishers to increase their portfolio of titles under management by fifty percent or even one hundred percent. Some internally focused game companies will suddenly jumpstart third-party publishing programs, and everyone has a new roster of “Bizdev” types on payroll, SDKs, and parties to host at various conferences.

Let’s blink and jump forward three years. We are halfway into the boom-bust cycle now, and some kind of Black Swan event is about to happen to poop on everyone’s parade. Around the time that this sadness is about to emerge, game publishers are starting to get real serious about their portfolio math. In this window of time, it is clear that adding as many titles as they did was a bad idea—and by a bad idea, I mean an expensive idea. Angry bean counters start running around the building armed with pink slip cannons, whooping and hollering like crazy people as they “right-size” the company.

The person who decided to add so many games to the portfolio has been pink-slipped, and his boss, in a desperate attempt to keep his job, has decided that the company will focus on the core franchises that make money.

I wish this were as funny in reality as I make it sound. These binge and purge cycles are unhealthy and cost people their jobs and affect their families.

I can respect that when we are headed for good times, you want to leap up and pull a Napoleon, screaming, “Audacity! Always Audacity!” I just think that is not a very wise idea. When things start to heat up, it is probably worth making some amount of cautious investment into adjacent areas and “off-the-roadmap” experiments. It is also very important to ensure that these are well-measured, and that there is consideration for the incoming bust cycle that invariably follows. I can imagine someone doubling the number of games they publish smugly, declaring, “This time, it will be different!”

Sadly, it never is. I have seen publishers declare they want to go from ten games under management to fifty games under management. By the time they have nearly thirty games ready to go, the marketplace shift is underway, and suddenly they are focusing on their best three games.

You can almost tell the time by the regularity of this sick game portfolio management pendulum swing.

I keep telling people that each of these articles is valuable if there is one single moment in time that someone is about to make a bad decision and they remember that I talked about why it is a bad decision. I don’t even care if they still go ahead and make the bad decision one more time. If they remember that I predicted this would happen and then decide differently the next time around, then all of this me-not-making-money-as-amazon-associate will have been worth it.

Having ridden this seven-year wave at least four times, you have no idea how sad this cycle makes me. I am emotionally spent writing this article from the Ozymandias-level destruction these waves cause. I am on the verge of tears, like when Spock dies in the only good Star Trek movie.

I am so saddened that I need to go to Amazon and buy one of these comforting huggable teddy bears to feel better. Does contemplating the binge-and-purge culture of game publishing make you sad too? You should buy this teddy bear to feel better. In fact, buy two. One for you and one for the person you care the most about. They will thank you for it.

I will see you next week, where I hope to be a little less “Look ye mighty on my works and despair!”

This week I want to take you back in time twenty years. It was 2004. I was on my way out from a year of employment at Digital Chocolate and getting back to running a game studio with a business partner and friend, Tom Hubina. That company was called Mofactor, and it is the URL where I host this blog and keep some of my “I am too lazy to edit the contact information” online services.

As the business leader for Mofactor, I made many mistakes, most of which were avoidable. There are a few that really puzzled me.

We made huge piles of mobile games, including some that did well. While we dabbled in experimental gameplay and attempted to raise money “because money,” we also funded our mobile studio through work-for-hire projects with multiple publishers.

We were not the most expensive mobile studio, nor were we the cheapest. When we were invariably asked by any publisher, “Can we get this project done any cheaper?” We generally said no. For a year of projects, we developed a rule of thumb:

For every dollar we spent on making work-for-hire content, we charged our partner one dollar for our own IP. On the surface, this sounded like a good plan. Regardless of what we put into the budgets, this seldom worked out. Intermittent delays, publisher change requests, and new handsets (with new handset bugs) all conspired against us. While we started with a 100% margin on our projects, this would get whittled away over time to almost nothing.

You could argue that we should have done a better job fighting this. Early mobile publishing was a strange place, and given the size of the budgets and the scope of the projects, it seldom made sense to do so. There was always a surprise bug in the handset. There was always a good reason to delay a launch. “The Carriers Did It” was our version of pointing at the dog after nasty gas.

We always sought to create some kind of leverage out of every one of these projects. For a small studio, we had a massive collection of phones and an impressive core library of software with workarounds for many handsets. At its peak, we released about twenty builds covering six hundred different handset models. Most of these games were smaller in binary size than the icons for the Apple App Store of today.

After each project, Tom and I would have a long late-night conversation. It was a form of post-mortem, where we looked at all the things that happened during the project and how that would impact what we did next.

There were far too many projects where we had so little profit on the work that we landed in the same place—as a small studio—as we had started, except that it was six months later.

We came up with a pejorative term to describe these projects.

“The only thing we got was older.”

It is a valuable expression that I still use today. There are times in sportsball games when you want to advance the clock, and those make sense. In life and business, that is less desirable. Sometimes, you want to defer decisions to maximize your business’s optionality and, ideally, create some value along the way.

If all you do throughout a project is marginally get closer to the heat death of the universe, you need to ask yourself: “Was this a good use of my time?”

Do not be too hard on yourself when it happens. It will happen. Acknowledging that you “just got older” is an excellent way to frame how you can do it better the next time.

See you next week!

If you have been here long, you will notice I have turned off forum discussions on my blog. Maybe I did not have the right tooling, but I got tired of spending more time clicking away trolls than approving comments. I am sorry if this is a feature you desired, and I game-ended it. The least I can do is give you an Amazon Associate Link to something to dry your salty tears. I appreciate you enough to ask you to help me steal nickels from Jeff Bezos, and I know in a week, when no one has ordered any, I will order a pack of these for some tears of my own.

So, what is this week’s topic? You know what? There isn’t one. I have this big pile of Post-its on the bottom of my immoderate forty-nine-inch monitor, and I am choosing to buy myself a week of blog backlog extension by doing none of them. Consider this some sort of perverse blog treatment of tech debt. I would invite you to comment on the sagaciousness of the idea, but I have turned off the comments. I hope you do not unsubscribe, mind you, if you indeed possess some kind of subscription to gaze upon these word-collections.

I have moved from Rocklin to Tustin in the past couple of months. I have children attending Southern California institutions of higher learning, and this move keeps me within helicopter-parent distance. Part of the move includes a downgrade in size and recency of the house. On the one hand, we have less square footage than we did previously, and on the other hand, the house is not so recently built that it has excellent air conditioning for the California summer. The net-net is that I had hoped to save some benjamins on AC costs, which has not manifested itself. We have also run into some interesting quirks that have me conducting experiments to mitigate our distance from the heat-death of the universe.

I am happy to discuss some of my interesting domestic tasks in detail. Ask away if you have questions! I have learned many things involving heat control, product assembly, and, of all things, multiple uses for Loctite. That we have reached a steady state and are no longer fully at war with all parts of the house is probably the important part of that story.

We are glad to be back within driving distance of several preferred vacation destinations for the kids and multiple restaurants I enjoy. We keep telling ourselves this, and maybe it is true.

Now that I am almost deep enough into the blog to hit the publish button without any outrage, I should reveal the sinister motives behind writing about nothing.

For starters, I have hit two million words processed by Grammarly. Hooray me! That is a lot of words for someone who does not write books. Okay, I did write books, but they were mostly bad. Two of them were boredom avoidance while commuting on a train; that is my story, and I am sticking to it.

Also, I had a regularly scheduled one-on-one meeting with my boss today, which was reasonably freeform. Usually, one or both of us have an agenda with several robust topics for discussion. Today, we just meandered through the universe of conversation like it was a classic episode of Star Trek.

And that is okay.

Yes. Sometimes it is okay to wander around conversationally instead of sticking to a formal agenda. I used to take some percentage of 1:1 meetings at a large company and go on walking meetings just to break up the routine. It feels nice.

We will return to my massive list of Post-its-as-blog-topics next week!

I am now on my fifth version of “The Definition of Done” at work—or is it the millionth? Much like the turtles in Ringworld, sometimes it feels like it is “Done” all the way down.

If you are early enough in a company’s existence, you will eventually find yourself here. You will sit in a room full of people who are all squawking like parrots. Half will be going, “Is it done? Is it done?” and the other half will be going, “It is done! It is done!”

And sometimes, in fact, the work is actually done.

The sad truth is that it might not even be the majority.

It begs the question: Who is responsible for saying something is done?

And why does that matter?

Oh, dear reader, I am sitting here and staring at my notes through blurry eyes, fighting back the tears as best as I can.

What happens when you say something is done when it is not? I want to ask the ChatGPT to rewrite my thoughts as if I were HP Lovecraft and the business processes are cast here in the role of He-Who-Is-Not-To-Be-Named. You will lose your sanity if you say the work is done three times! How else to capture the horror of shipping software that is not done?

Half of you are rolling your eyes now. Declaring something done cannot be that hard, can it?

But what does it mean to be done?

Developer Done

This is always the slipperiest. From all of the “it works on my machine” memes to 8.5 million machines dying on Crowdstrike Friday, see the news if you do not get the joke. Most organizations default to Developer Done as some sort of holy declaration that is hard to prove true and eventually hard to believe. While making sure that lots of stuff is committed to the repo and put into PR after it has been tested by the original developer, this is the most dangerous of all of the Dones to me.

Quality Assurance Done

Here is our second flavor of done. Someone produced a checklist or test suite to ensure basic functionality works. A script or a worker-bee has driven through this checklist, and everything has a little green tick mark or a little yellow question mark. The question marks are annotated as “pass with notes” in some suspicious-looking document that The Stakeholders scrutinize. There are holes here too. You can have something that is defect-free and yet, not done.

Product Manager Done

Done version three is another layer, like some sort of business onion. Your developers can be done, and your testing can be done, but does it do what the product owner envisions? There is some Marcus-Aurelius-level thinking that goes into this, and we can ask ourselves about the nature of the thing. This gets us pretty close to “ackshully” done if you ask me.

Contractual Obligations Done

A fourth and equally interesting flavor of done is the Contractual Obligations Done. Is this a layer of business onion? This may be where the onion theory falls apart. It is too bad, I would have loved a side of business onion with lunch today. This is a tricky one because if you are going through a legal checklist of stuff to declare it done, you might find that you are technically done, and yet, you miss out on the next and most important kind of done.

Customer Done

This is a pretty important flavor of done. When you have built your software Macguffin, does it indeed Macguff sufficiently? Do customers smile, and do onlookers exhibit symptoms of surprise and delight?

There are many definitions of done, and none of them are correct in their entirety. It is important that everyone involved can sufficiently proclaim something done for us to have a true enough done for any particular piece of software. If we do not have sufficient rigor to reach the right level of consensus on done, then we will falsely declare something as done.

Falsely declaring something as done is dangerous. Even more frightening to the shareholders, falsely declaring something as done is expensive. A plethora of companies will attempt to help you get there from here at two to eleven dollars a month per active employee, and you can email them to ask for enterprise discounts.

Phew, I am spent. I hereby declare this blog post as done.

Wait, not yet.

First, I must implore you to Socials about this—TokTok, Twitter, and LinkedIn. I still have fifteen unspent minutes of fame directly resulting from you doing nothing every time you come here.

See you all next week!