Artisanal Concatenations of Sentient Emanations

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!

If you have been in enough meetings with me, you will see shadows and glimpses of angry John from years ago. I have done the math and have determined that most people are eligible for four to eleven hours of active meeting non-aggression. At that point, I have to go down a flowchart with words like “business customer” or “pays my salary” to determine if I re-up those hours. If you hit zero, I will attack you like a nineteen seventies cigarette ad, which means I will attempt to reshape your daily habits and make you look cooler to everyone around you.

I wish to crumple up and toss at least one of your habits into your mental waste bin. It is not your most obnoxious behavior; it is your use of double negatives. Perhaps thou didst observe what I didst there. There is nothing that chaps my jimmies quite so much as the thoughtful person at the end of the table nodding over their steepled fingers and raising an eyebrow to state, “That is not a bad idea.”

This just in: It could be a good idea.

Let’s set that aside for a moment, along with the gaslighting you get from being told your idea isn’t that bad.

The deep truth is that most ideas are, in fact, bad ideas.

And that is okay.

Having bad ideas does not mean you do not have good ideas. In fact, having bad ideas is a necessary condition for having good ideas. Everyone has some internal ratio of bad ideas to good ideas; generally speaking, the number of bad ideas you have is larger than the number of good ideas.

This is still okay.

It is important to tell you that this is okay and you are okay.

I have just as many bad ideas as the next person, and I have accepted this.

People participating in ideation might already know this deep secret of Idea Making… Perhaps they do not. Your goal is to have as many ideas as possible and have a safe enough place where your ideas can be shared so that you do not suffer ego death when someone takes a raging dump on them. Ideas should live or die by their merit. You will eventually find your ratio of bad ideas to good ideas, and as you succeed with good ideas, your volume of bad ideas needed per good idea will go down.

In early mobile game development, I reached the point where one idea out of five was good. Each good idea at that time generated enough revenue to fund six more games. Based on that math, the odds were reasonably good that I could keep making games and publishing them profitable enough to live to ideate another day.

I have already talked elsewhere about “not a bad idea.” The point I want to make today is that you need to have a thousand bad ideas to generate any number of good ideas.

It is okay to say something is a good idea. It is also okay to say something is a bad idea. The most important thing is to keep having ideas and improving your tools and filters to know which is which.

With that in mind, it is time to talk Amazon-Affiliate-Linked-Recommendations.

Good idea: Delicious 16-Year-Old Lagavulin Scotch Whiskey. It puts out the fire and keeps in the warmth!

Bad idea: A 36-pack of alcohol-free White Claw. My own experience with White Claw is limited to “I was there when it happened, officer,” and that is how I want it to be. I cannot fathom that there is a customer out there for one, let alone thirty-six cans of “The Taste of White Claw.”

You may now take my very best Greta Thunberg stare into the weekend. It will be a great weekend if you hurry up and get an amazing bottle of scotch from above. I have no idea what kind of weekend you will have with that many alcohol-free cans of White Claw, but you have a right to do you.

I wish I could say that today’s blog post was delayed so I could experiment with posting schedules—it wasn’t. As parents and professionals, sometimes we fail to make enough time. I forgive me, and I hope you forgive me too.

On the subject of time, I am staring at my calendar today and asking myself a plethora of questions. Why does this look like Swiss cheese? Who hates me so much to schedule so many meetings so haphazardly? How will I fit all my one to two-hour tasks into these tiny thirty-minute holes?

I started by taking the first of those thirty-minute meeting gaps and scheduling a meeting with me as the only attendee. The meeting subject I chose was “Feel sorry for myself.”

It would be easy to do that for all the remaining thirty-minute chunks of time. Then, I would look busy on paper and feel really smug about how self-satisfying that is. Unfortunately, none of the really important stuff I needed to do would get done.

Shelley wrote about this when he wrote: “Look on my Works, ye Mighty, and despair!”

Are you super-sad for me yet? Sad enough to need an Amazon-Affiliate-Linked box of Kleenex (most popular?)

I didn’t think so.

So, what can you do to preserve some calendar time and some sanity?

Good reader, I want to remind you that there are companies out there that have created packs of six hot dogs, and other companies that have created packs of eight hot dog buns. This is a very real problem.

I have decided that I am going to apply an anti-pattern here and lean into the two-bun gap.

The best way to preserve my sanity is to reverse-defrag my calendar.

Let me explain. Everyone loves a thirty-minute meeting. To preserve my sanity, I will start scheduling forty-five-minute meetings and “do not book” blocks.

For everyone else out there, stuck in their thirty-minute thinking, all their meetings will start at the top of the hour or half past. They are going to either help add fifteen minutes to my anxiety-inducing gaps, which makes them slightly more useful to me, or book them so that I only have fifteen-minute gaps, which I will use to turn away from my computer and scream into the void.

Insert a double-finger-guns emoji here, and profit. Win-win here amirite?

In all seriousness, we are ruled by our calendars, and scheduling can feel like warfare. Sometimes, you need to bear down and get stuff done. You can do things to create odd-shaped gaps in your calendar if you need to.

Conversely, this is also a tool you can use to help your fledgling leaders delegate more. On one hand, you can schedule a handful of forty-five-minute meetings with them. On the other hand, in more extreme cases, you can book an hour or even longer to ensure they don’t have time to cannibalize their teams by doing IC work.

So now we find ourselves at the end of another weekly blog post, and everyone is wondering, “Is John fucking serious?”

Maybe. Sometimes, you have to get serious to get stuff done. And if that means you need to turn the calendar into a weapon, so be it. Eat those six hot dogs and those six hot dog buns.

You will thank me when you are all finished, and you have tossed the two expired hotdog buns in the trash.

See you next week!