Jerry Nixon @Work

Floods, Tornadoes, Hurricanes, and Wildfires

2025-10-02T14:57:00.001-06:00

In the U.S., we’ve always had floods, tornadoes, hurricanes, and wildfires. What’s new is how many people now live in the paths of those risks. Cheap housing, job growth, and lifestyle have pulled people into places that once were left alone. I get it. But the storms still come.

It’s very possible, even likely, that the rising cost of storm damage isn’t just about stronger storms. It’s about what we’ve built in their way. Since 1980, the U.S. has seen nearly 400 billion-dollar disasters. Climate change grabs the headlines, but many experts agree the real cost driver is us.

We’ve packed more homes, businesses, and infrastructure into risky zones. Florida is a good example. The fifteen counties hit by Hurricane Milton grew from 3.7 million people in 1980 to over 9.1 million in 2023. Their economic output more than quadrupled.

The same story plays out with wildfires. From 1990 to 2020, homes in fire-prone areas rose by 47 percent. That is not just bad planning. It is stacking kindling.

Look at Hurricane Helene. Damages reached $250 billion. Not just because it was strong, but because there was more to destroy. Our choices, more than the climate, drove the cost.

California shows it too. In early 2025, the Palisades Fire tore through Los Angeles, destroying more than 16,000 structures and forcing 200,000 people to evacuate. Estimated losses hit $275 billion. That may be the most expensive natural disaster in U.S. history. Again, it was not just the fire. It was what we built in its path.

North Carolina tells the same story. When Helene stalled over the mountains in 2024, record rainfall overwhelmed rivers and flooded towns like Asheville, built in the floodplain.

Now the Midwest is getting hit. Over Easter weekend, a slow-moving storm dropped tornadoes, hail, and flooding rains across Oklahoma and Texas. It used to be trailer parks and shanties that took the worst of it. Now it is McMansions and standard suburbs built in places that probably should never have been neighborhoods.

Since 1980, the U.S. population has grown from 227 million to more than 344 million. That is a 50 percent jump. Much of that growth has been in high-risk zones: coastal counties, floodplains, and fire-prone hills.

Today, nearly 40 percent of Americans live near the coast. The number of people in high fire hazard zones grew from one million in 1990 to 2.6 million by 2010. In 2023, high-risk metro areas grew 35 percent faster than low-risk ones. As more people move into vulnerable places, the cost of storms keeps climbing.

Unless we rethink where and how we build, the financial toll will only rise.

It is easy to blame climate change for expensive storms. But the truth is more complicated. It is both nature and human choice. And if we are honest, the largest factor is not temperature. It is us.

Plates Weighing 130 Shekels

2025-10-01T14:54:00.001-06:00

This morning I learned something. When I read “each silver plate weighing 130 shekels” in Numbers 7:85, it hit me that I had always thought a shekel was only a currency. Turns out it started as a unit of weight, and that sent me down a rabbit trail.

A shekel equaled about 11.4 grams of silver, or 0.025 pounds. A coin that weighed one shekel became worth one shekel. Value matched weight.

The shekel began in Mesopotamia around 2000 BC as a unit for trade. By the time it entered Israelite life around 1000 BC, it was standardized for religious use. “The shekel of the sanctuary” referred to the official temple weight, probably kept by priests to keep offerings fair. Later, during the Persian and Hellenistic periods, silver shekel coins were minted and circulated across the region. The shekel faded after the Roman era but came back in 1985 as the New Israeli Shekel (NIS), Israel’s current currency.

The British pound followed a similar path. It also began as a unit of weight. One pound of sterling silver equals 16 ounces, 7,000 grains, or 453.6 grams. That pound was divided into 240 pennies. So one ounce was valued at 20 pence. Why 20? There’s no clear law or decree. The Roman system divided a pound into 12 ounces, and over time each ounce came to be valued at 20 pence. It seems to have been a practical convention that stuck.

The old British system included shillings, crowns, and farthings. One pound was 20 shillings, one shilling was 12 pence. A crown was worth 5 shillings (60 pence). A farthing was one-fourth of a penny. It was layered, but people worked it out.

The official weight standard was literally stored in the Tower of London. All coins were compared against it to ensure they were honest. That was the physical “pound sterling.” In 1971, the UK switched to decimal: one pound = 100 new pence.

By contrast, today the metric system defines standards differently. The gram used to be defined by a platinum-iridium cylinder stored in France, but since 2019 it is tied to the Planck constant, a fixed value in physics, measured with a Kibble balance. No more chunks of metal in vaults. Now it is universal and grounded in nature itself. Honestly, I thought it was still physical until today.

So what about the pound today? In the US and UK, the pound is now officially defined by the metric system: exactly 0.45359237 kilograms. Ironically, the old imperial unit now depends on the very metric system it once resisted. No reference bar, no coin, just math.

Now you know what I know. Good morning.

Dolus specialis and Genocide

2025-10-01T10:15:00.001-06:00

TIL: Dolus specialis.

Dolus specialis is a Latin legal term used in international criminal law. It refers to a special form of intent, one not satisfied by general criminal intent alone but requiring a heightened intent directed at achieving a particular prohibited outcome.

Etymology:

dolus = intent, deceit, intentional wrongdoing
specialis = particular, distinguished from othe

Together, dolus specialis means “special intent.”

In law, this concept is crucial. Ordinary crimes may only require dolus generalis (general intent), such as intending to commit an act regardless of any larger purpose. But some crimes, like genocide, require dolus specialis: the specific intent to destroy, in whole or in part, a national, ethnical, racial, or religious group. That extra layer of intent distinguishes genocide from the many other horrors of war.

This is very relevant to what’s happening in Israel right now.

Legal Accusation

Several UN bodies, human rights groups, and governments have argued that Israel’s military response in Gaza since October 7, 2023, meets the definition of genocide. They cite the enormous civilian death toll (over 40,000 according to Gaza authorities), widespread destruction of infrastructure, and mass displacement of more than 90% of Gaza’s population. They also highlight incendiary public statements by some Israeli officials, which appear to show an intent to destroy Palestinians “as such.”

South Africa’s case before the International Court of Justice (ICJ) in December 2023 crystallized these accusations. It alleged that Israel’s actions, including bombings, ground operations, and restrictions on food and medicine, constitute genocide under the 1948 Convention. The ICJ, while not ruling on the merits yet, has issued provisional measures three times, finding there is a “plausible risk” of genocide. These measures require Israel to allow humanitarian aid and prevent genocidal acts, though they stop short of declaring that genocide is actually occurring.

Intent Debate

The heart of the debate lies in dolus specialis. Genocide requires more than death, destruction, or suffering. It requires proof of specific intent to eliminate a group. Historically, genocides like the Holocaust, Rwanda, or Cambodia revealed that intent unmistakably through death camps, organized massacres, written policies, and systematic targeting of a group’s very existence.

By contrast, the situation in Gaza is complex.

Most Palestinian deaths have occurred through urban warfare, bombardments, and military strikes, not systematic roundups, executions, or extermination camps. Israel has made evacuation warnings, facilitated some humanitarian aid, and targeted its rhetoric toward defeating Hamas rather than Palestinians as a whole. These facts complicate the assertion of dolus specialis.

On the other hand, Israeli officials’ extreme statements, such as calls to “erase Gaza” or referring to Palestinians as “human animals,” are cited as evidence of genocidal incitement. Critics argue that even if Israel’s official war aim is the destruction of Hamas, the sheer scale of civilian harm combined with such rhetoric amounts to intent by conduct.

Comparisons

Genocide archetypes: The Holocaust used extermination camps. Rwanda saw systematic machete massacres. Cambodia carried out forced starvation and executions. In each, the intent to annihilate was unmistakable.

Gaza context: Civilian deaths are enormous, but largely as collateral damage from war against an entrenched militant group that embeds itself in civilian infrastructure. The devastation is real but different in method and arguably in intent.

Aid and survival: Israel’s allowance of some humanitarian aid, however limited, is sometimes viewed as contradicting genocidal intent, since genocide traditionally involves total deprivation of survival needs. Others argue this allowance is merely tactical and does not absolve intent if the broader conduct shows destruction.

Hamas and Dolus Specialis

It is also worth noting that many legal scholars point out Hamas’s intent toward Israelis reflects dolus specialis more clearly. The October 7, 2023, attacks deliberately targeted civilians, including systematic killings, kidnappings, and massacres. Hamas’s founding covenant and public statements call for the elimination of Israel and Jews, aligning directly with genocidal intent. Scholars from The Atlantic, The New Yorker, and security experts describe this as genocidal rhetoric and action, with antisemitic tropes echoing Nazi-like propaganda.

This contrast highlights the difficulty.

Israel is accused of genocide largely by inference, while Hamas openly declares it.

Political Context

The debate is inflamed by the geopolitical stage. The U.S. continues to back Israel with military aid and diplomatic cover, citing security concerns and alliance commitments. Some states and international bodies use genocide language both as legal argument and political pressure. Meanwhile, accusations of genocide have historically been misapplied to Israel, such as in 1948 and 1967, making some observers cautious of political motives behind the charge.

Inside Israel, the accusation of genocide is largely rejected, viewed as unthinkable given Jewish history. For Jews worldwide, the charge resonates painfully, especially as antisemitic attacks increase in other countries.

Bigger Picture

Genocide is not simply a synonym for mass suffering.

It is a precise legal term requiring proof of special intent to destroy a group as such. The ongoing case at the ICJ shows that proving this intent is far harder than recognizing devastation.

Applying the word genocide to Israel’s actions may be reductive.

It risks collapsing the complexity of war, strategy, propaganda, and tragedy into a single trigger word. The result can be less about legal precision and more about political weaponization.

None of this diminishes the suffering in Gaza.

The civilian toll, the displacement, the destruction of homes and hospitals, all are catastrophic and cry out for an end. But whether those realities constitute genocide is a distinct and difficult legal question.

We Must Hold

We can affirm two truths:

That applying “genocide” simplistically may be more about echo chambers, programming, and propaganda than about legal accuracy.
That the devastation in Gaza is intolerable, that Israeli sovereignty matters, and that Jewish communities face precarious dangers as antisemitism rises globally.

Word matters, but so does the reality.

What matters most of all is the desire to see this end, for Palestinians, for Israelis, and for the stability of a region where peace feels impossible yet remains essential.

Just a thought on Senator Kennedy

2025-09-30T12:27:00.005-06:00

I am trying to resist the tidal wave of programming pushed at me about Secretary Kennedy. I hear friends and family parroting anti-everything talking points that gloss over reality and try to dehumanize and derail every word he says. Instead, I pause and actually listen. I want context, not spin.

Please don’t get triggered. I’m just trying to explain what I feel when I hear the Secretary announce this and that. It’s not as black and white as the talking heads want you to believe.

We’ve never experienced someone in this kind of position with his level of passion combined with his level of carte blanche authority. I don’t think he’s trying to get rich, and people saying he is stupid are clearly pawns of backroom propaganda.

If anti-vax, anti-science, or undermining the medical establishment are the first things you hear when his name comes up, you may need to ask yourself whether you’ve absorbed programming you didn’t realize.

Honestly, I think he’s in the position of his life and seems imbued with a level of urgency that might actually result in change. He really seems to be on the side of the American public and unpartisan in that sense. It’s not something we’ve experienced much of, so I understand why people are suspicious to a degree.

These propaganda machines make no sense to me, and neither does the susceptibility of people drinking it all up. They push vapid claims, unredeemable vitriol, and out-of-context clips to insinuate manufactured nonsense for someone who hasn’t earned that treatment.

As for me, I’m cautiously optimistic that the status quo, which we can all agree is problematic in so many ways, might finally be at risk. If Kennedy is wrong, whatever he accomplishes can be undone. And frankly, once he is out of office, the powers against him will likely undo everything he manages to accomplish anyway. Sigh.

Ref: https://x.com/i/status/1973066020471341312

The weariness of caring deeply

2025-09-15T20:54:00.004-06:00

It’s been three days since Charlie Kirk was shot. I have to admit I never watched his show, listened to one of his speeches, or followed him online. My only exposure was the “change my mind” meme and the occasional short clip of a Q&A with a student. Honestly, I’m not sure I would have recognized him in a crowd. It was only this week that I learned Turning Point was his production company.

Still, I’ve been thinking about this event a lot. As I’ve learned more about his life, his faith in Christ, and his relationship with his wife, the weight of it has grown heavier. I feel disappointment. Disappointment in the behavior of the young shooter, disappointment in the loss of Charlie’s voice, and disappointment in the irreverent hostility of so many who clearly do not understand what he actually said or what this actually means.

Yet disappointment is not the strongest feeling. At first, I wondered if I was sad or even depressed. But watching how some gladly smear a lifetime of faithfulness for a moment of political gain, I realized it is not depression. It is exhaustion. Exhaustion from constantly pushing back, holding back, and keeping in the pressure not to react in some terrible way. Exhaustion from refusing to let go of integrity, even when everything around seems to encourage cynicism or cruelty.

I suspect many of my friends who say they feel depressed over recent events are really feeling the same thing: exhaustion. The broken part of us looks for a chance to rise up in moments like this, to take advantage of our weakness.

Well. It will not be today.

Roy F. Baumeister, a social psychologist, described this as ego depletion, the idea that self-control draws from a limited pool of mental resources. Using willpower in one area temporarily reduces our capacity in others. He compared willpower to a muscle: it can be fatigued when overused, but it can also be strengthened through practice.

Perhaps today is a kind of spiritual leg day at the gym.

I believe this puts a fine point on the reason God so frequently brings up the idea of rest. Rest is not just idleness but a spiritual discipline that renews strength, clears perspective, and recharges the soul. Without it, exhaustion makes us vulnerable to despair and rash reaction. With it, we remember who we are, whose we are, and that the battle is not ours to win in our own strength.

Matthew 11:28 “Come to me, all you who are weary and burdened, and I will give you rest. Take my yoke upon you and learn from me, for I am gentle and humble in heart, and you will find rest for your souls. For my yoke is easy and my burden is light.”

I have always felt encouragement when I consider that Jesus Christ was the man who literally had the weight of not only the entire world on his shoulders, but the weight of the entire world through all of time. How he could refer to the weight he had to bear as light and easy. In that moment he let slip not just how important he is, not just how serious he is, but how unimaginably powerful he is.

Why someone like that, the King of the universe, would condescend and take a knee just so he could look someone like me, his mortal enemy, in the eye and express his tireless love still strikes me. Why he would willingly proceed to the cross for my sake. Why he would willingly suffer on the cross for my sake. Perhaps I will never fully understand. But at the least, I will believe him.

Romans 12:14-21 "Bless those who persecute you; bless and do not curse. 15 Rejoice with those who rejoice; mourn with those who mourn. 16 Live in harmony with one another. Do not be proud, but be willing to associate with people of low position. Do not be conceited. 17 Do not repay anyone evil for evil. Be careful to do what is right in the eyes of everyone. 18 If it is possible, as far as it depends on you, live at peace with everyone. 19 Do not take revenge, my dear friends, but leave room for God’s wrath, for it is written: “It is mine to avenge; I will repay,” says the Lord. 20 On the contrary: “If your enemy is hungry, feed him; if he is thirsty, give him something to drink. In doing this, you will heap burning coals on his head.” 21 Do not be overcome by evil, but overcome evil with good."

We often comment that Jesus’ economy is an upside-down economy. What we see in this world almost always works the opposite and stands in opposition to what Jesus actually teaches. But if he is anything, he is consistent. From Genesis to Revelation, God constantly expresses his love for us in the context of just how much he wants to handle our difficult moments.

God does not want his children chasing vengeance or waving the banner of bitterness. Though we were designed for great things, it is not just that we cannot carry this weight, it is that we were never supposed to carry it. He is the one offering us rest; he is not asking for rest from us. Some of the most difficult moments of obedience are the ones where we thoughtfully and intentionally do nothing at all. It is a new banner to fly, one that declares we trust and obey, that he will do what he says he will do. There is no other way.

Surrender on the battlefield is different than this kind of surrender. Our shallow, vapid, and almost silly version of justice cannot deliver; it is enthroned with failure and so often becomes the recipe for the deepest injustice. We do not even mean well, we simply want to be right. But when we surrender to God’s justice and abandon our own nonsense, we are surrendering to what may be the finest of all things, the most emblazoned jewel in the crown of the King.

What amazes me is how we are told to do this. The fundamental blueprint for the Christian life is simple: read the Bible, obey the Bible, and share the Bible. Yet as we read, the Scriptures practically shout another command that runs right alongside those three. That command is prayer.

Philippians 4:6-7 "6 Do not be anxious about anything, but in every situation, by prayer and petition, with thanksgiving, present your requests to God. 7 And the peace of God, which transcends all understanding, will guard your hearts and your minds in Christ Jesus."

I grew up in a home where prayer was more formal than familiar, but I have since learned it can be both without conflict. As I have grown older, I have come to see that many of the so-called paradoxes of the faith only appear that way because of my own narrow, single-minded perspective. I once fought hard to reduce competing and cacophonous ideas down to one, thinking simplicity meant truth. But the longer I walk with God, the more I see that true theological harmony comes when I accept the mystery and allow multiple notes to fill the room.

Paradoxes reveal the glory of God and our own. The sparks of iron sharpening iron are not meant to push me to erase complexity simply because it confounds me, but to help me embrace the joy of knowing that God will never fit into a neat little box. 1 Corinthians 2:7 "7 No, we declare God’s wisdom, a mystery that has been hidden and that God destined for our glory before time began."

Oh Lord my God
When I in awesome wonder
Consider all the worlds
Thy hands have made
I see the stars
I hear the rolling thunder
Thy power throughout
The universe displayed

Prayer is speaking to God in a way that not only he hears, but we hear too. It is the spiritual communication that forms the foundation of our relationship with him. Just as Jesus wept at Lazarus’ tomb, even though he knew he would raise him in moments, God wants to hear from us even though he already knows our every thought and counts every hair on our heads.

Prayer also humbles us mentally, verbally, and physically, drawing us into a posture that moves us toward repentance. On the one hand, our personal engagement with him as we lean in and listen reminds us of his everlasting and inexplicable love for us. We experience his goodness. And as Romans 2:4 reminds us, God’s kindness leads us to repentance. And what is repentance other than the first step in reconciliation, the finest of all the good things we can ever experience in this short life.

Then again, think of it like baptism; it is a public commitment to Christ, just as a wedding is a public commitment to a spouse. In the same way, prayer reminds us and renews our commitment to put our full weight on God. Even the vaporous whisper under our breath in the dark, shrouded in tears, is a spoken declaration of our true circumstance, our actual need, and our reliance on Jesus to ransom and rescue us from this dark world of our own making.

Sometimes we don't know what to say and we use liturgies or prayer formulas to get us through the night. Sometimes we don't know what to say and the Spirit of God steps in and speak son our behalf. All of this reminds me of a favorite song, Better than a Hallelujah. It's haunting chorus sings:

We pour out our miseries

God just hears a melody

Beautiful, the mess we are

The honest cries of breaking hearts
Are better than a Hallelujah. Sometimes.

Looking back, regrets, I’ve had a few. And if I am honest, far too many to mention. I have never subscribed to the sad notion that we should live with “no regrets.” Even God had regrets. The Lord told Samuel he regretted making Saul king, and in Genesis, just before the flood, he regretted making human beings on the earth. Where God regrets the choices we made, my regrets are the choices I made.

For me, though, a big one is the lack of faith I showed when I didn’t turn to prayer. Here’s what I mean: if I truly believed, I wouldn’t have been able to stop. Like jumping out of an airplane without a parachute, I ran into this broken world with nothing but my bare hands, and I wasn’t ready. The truth is, I could never be ready to do it all on my own. The showcase of all my regrets is that I haven't believed enough in God’s faithfulness to make prayer an unceasing part of my life.

And so, we circle back to the beginning. How tired am I of trying to do it all on my own? With the assassination of Charlie Kirk, I feel pulled into the whiles of my own imagination, inventing remedies born out of logic and reason as if they could fix what is broken. But how foolish I have been, and how deeply exhausted it has made me.

What I need, what we all need, is not more striving but more surrender. Not more clever answers, but more prayer. Not more weight on my shoulders, but more trust in the one who already carried it all to the cross. If there is anything this moment teaches me, it is that my exhaustion is not meant to push me on over that cliff, but to pull me back to King Jesus.

What a friend we have in Jesus
All our sins and griefs to bear
What a privilege to carry
Everything to God in prayer

Oh what peace we often forfeit
Oh what needless pain we bear
All because we do not carry
Everything to God in prayer

It is the glory of God to conceal a matter; to search out a matter is the glory of kings.

The English Word: Secretary

2025-03-28T15:01:00.001-06:00

With all the recent headlines about government secretaries, I found myself wondering how secret and secretary are related. As it turns out, they are very closely connected.

Both words trace back to the Latin root secretum, meaning something set apart, hidden, or private.

Originally, a secretary was not simply someone who typed letters or kept calendars. A secretary was a trusted person who managed confidential matters, literally someone entrusted with secrets. In Medieval Latin, the term secretarius referred to an official handling private affairs for a ruler or noble. By both title and function, secretaries were keepers of secrets.

Over time, the word shifted. Today, we no longer use secretary as a professional title in most contexts, except in government. In business, secretary has been replaced with roles like assistant or executive administrator. This kind of linguistic recategorization can be frustrating for English learners, much like when “stewardess” gave way to “flight attendant.”

Still, to be the Secretary of State or Secretary of Defense carries no diminishment. The title signals authority and responsibility, not clerical support. Likewise, the UK’s Minister of Foreign Affairs is not assumed to be a religious figure. Both words are shaped by history and context.

Minister itself comes from the Latin minus, meaning lesser or subordinate. A minister, whether in government or religion, is one who serves a higher purpose, whether that is the state, the public, or God.

And what about secrete? It also comes from the same Latin root, with the sense of “to separate.” The word took on a biological meaning and has been stuck there ever since. It may be an etymological cousin, but one that lives in a very different neighborhood.

About $4.3 Trillion in New Investments?

2025-03-24T15:03:00.001-06:00

Last week I mentioned that major economic growth engines are being spun up in the U.S. with new investments on a massive scale. Here is a list of the biggest announcements so far. Together they add up to about $4.3 trillion in new investment beginning in 2025. The list keeps growing, but even now it gives a clear sense of the scale.

If you are trying to decide whether the next several years will lean bearish or bullish, this might help.

United Arab Emirates: $1.4 trillion, a 10-year investment framework targeting U.S. sectors such as AI infrastructure, semiconductors, energy, and manufacturing.

Hyundai Motor Group: $20 billion, including a $5.8 billion steel plant in Louisiana, designed to localize production and reduce the impact of future tariffs on foreign-made metals.

Taiwan Semiconductor Manufacturing Company (TSMC): $100 billion to establish three new advanced semiconductor plants, greatly expanding domestic chip manufacturing capacity.

Saudi Arabia: $600 billion over four years, pledged by Crown Prince Mohammed bin Salman to President Donald Trump, aimed at strengthening economic ties and diversifying Saudi investments.

Apple Inc.: More than $500 billion over the next four years to expand U.S. manufacturing and research, including a new AI server facility in Texas.

Eli Lilly and Company: $27 billion in additional investment to increase domestic drug production, bringing its total U.S. manufacturing commitments since 2020 to more than $50 billion.

GE Aerospace: Nearly $1 billion to reinforce U.S. manufacturing and supply chains, along with hiring 5,000 American workers.

Stellantis: $5 billion into its U.S. manufacturing network to expand vehicle production.

India: Companies such as ReNew are expanding exports to the U.S. to help fill the gap created by China’s exclusion from the U.S. solar market.

Japan: $1 trillion pledged to U.S. industries, including defense and AI, in a move to reinforce U.S. military partnerships in the region.

Australia: $798 million payment to the U.S. under the AUKUS deal, strengthening the defense industrial partnership and supporting nuclear-powered submarines.

Nippon Steel Corporation: $14.9 billion proposed acquisition of U.S. Steel, aimed at bolstering American steel production.

OpenAI: $500 billion Stargate project in partnership with SoftBank, Oracle, and MGX to build U.S. AI infrastructure by 2029. SoftBank is also investing up to $25 billion in a Japan-focused joint venture.

Microsoft: $110.3 billion to build an AI hub and data center campus in Wisconsin, along with partnerships with BlackRock, Nvidia, and MGX to expand U.S. AI infrastructure.

Maersk Line: $2 billion redirected to expand East Coast port capacity, spurred by lower shipping costs and fewer delays compared to Panama Canal routes.

Boeing: $4 billion in new assembly and logistics facilities, capitalizing on rerouted shipping that avoids Panama Canal bottlenecks.

Delta Air Lines: $1.2 billion fleet upgrade to more fuel-efficient aircraft, supported by stabilized U.S. supply chains and increased air cargo activity.

Hanwha Aerospace (South Korea): $2.5 billion share sale to fund international expansion, including new U.S. manufacturing bases, to meet rising defense demand.

These announcements also ride on short-term policy factors. Reduced regulations and a lighter corporate tax environment have combined with global instability to redirect capital into the U.S. The bet is that American manufacturing and innovation will accelerate.

The next few years could see job growth, stronger infrastructure, and a new wave of technological leadership.

With plenty of caveats, of course.

The Battlefield of Language

2025-03-05T15:09:00.001-07:00

I am writing this with my teeth clenched, my eyes squinted, and my fingers striking the keys harder than they should. I know only the choir will hear this sermon, yet I write it anyway. If nothing else, it is a vent.

The English language today has been weaponized. Ordinary words have become dog whistles, ideological tests, or verbal traps that make honest conversation nearly impossible. In trying to control the narrative, we have stripped words of their utility.

Talking about discrimination is risky. Words like racism, sexism, colorism, sizeism, ageism, ableism, marginalized, disadvantaged, and oppression now signal ideology more than reality. Terms like underrepresented, bias, orientation, identity, race, gender, intersectionality, POC, descent, and minority shift meaning depending on the speaker. Discourse becomes a minefield.

Other words demand ideological conformity. Microaggressions, allyship, diversity, inclusion, equity, systemic, white supremacy, colonialism, decolonization, and land acknowledgment are wielded as litmus tests. Even merit, fair play, and quota are reinterpreted as either oppressive tools or necessary correctives.

Critiques of social structures such as heteronormativity, cisnormativity, patriarchy, transphobia, homophobia, xenophobia, Islamophobia, and anti-Semitism serve to sort people into categories of enlightened or irredeemable. Activist language like neurodiversity, environmental justice, restorative justice, trigger warning, safe space, cultural appropriation, and performative activism mark tribal boundaries more than they solve problems.

The same is true in psychology and gender. Gaslighting, implicit bias, intersectional feminism, non-binary, genderqueer, misogyny, misogynoir, anti-racism, critical race theory, whiteness, Latinx, BIPOC, QTPOC, deadnaming, misgendering, and gender dysphoria have been weaponized to demand allegiance. Disagreement is treated as bigotry.

Activism itself is saturated with loaded terms. Body positivity, slacktivism, virtue signaling, call-out culture, cancel culture, emotional labor, food justice, health equity, indigenous rights—all of these words are used as shields or swords, depending on who wields them. Even resistance and protest, once celebrated as pillars of democracy, now mean entirely different things depending on who is marching and why.

Health and medicine are not exempt. Political labels such as democracy, fascism, authoritarianism, Christian nationalism, and insurrection are deployed to create fear, not dialogue. Nations themselves have become triggers: Russia, Ukraine, Israel, China, even Canada. Mention Trump, Biden, Putin, Congress, or Elon Musk, and discussion collapses. The figure becomes either idol or villain, with nothing in between.

Even moral language has been tainted. Virtue, tradition, submission, family, homemaking, happiness, good and evil, right and wrong were once pillars of meaning but are now recast as political signals.

So how do we move toward understanding and compromise when the vocabulary itself is a battlefield? Words once meant for clarity and connection are now weapons. The wrong word at the wrong moment is no longer a slip; it is a declaration.

We need to start rejecting the machinery of triggers, not as private sensitivities but as deliberate schemes to fracture society. If we must be intolerant of anything, let it be the forces that back us into corners where division and hostility are the only possible outcomes.

Reject justice that requires a victim. Reject hatred and disparagement as solutions.

If our words cannot heal, they will continue to wound. And if we allow language to remain a battlefield, we will keep losing, not to our enemies, but to ourselves.

AI Will Not Replace Human Engineers

2025-02-14T15:12:00.002-07:00

AI will not replace human engineers unless it can do a better job than they can. Simply being faster is not enough, because engineering is not just about producing code. It is about solving problems, anticipating failure, designing for scale, and making trade-offs that affect real people and businesses.

In expansive systems, human engineers bring something AI cannot replicate: the ability to anticipate problems before they occur. That ability is not magic. It comes from years of experience across many contexts, seeing where things have broken in the past, and recognizing subtle signals of risk. A human can zoom out to see the full system and zoom in to identify a single faulty assumption. That combination of depth and breadth is what turns programming into engineering.

From my own experience using AI as a coding partner, I have found it helpful for small, isolated tasks. It can produce snippets, boilerplate, or quick scaffolding. But as models grow larger and supposedly more advanced, their practical coding skills do not show the same trajectory. It feels like we have hit a plateau.

Too often, I find myself correcting the model. I end up teaching it about syntax, approach, or even the very concepts it is meant to apply. Without my intervention, the task would stall. In other words, if I were not in the loop, the work would not get done. The AI is only useful because I am present to steer, guide, and validate.

This is why the casual claim that “AI will replace engineers, it’s just a matter of time” falls flat. Such statements reduce engineering to code generation, as if software were nothing more than lines of syntax strung together. They also reveal that the speaker probably is not using AI to write real, production-quality code. Anyone working with it daily sees both its promise and its limits.

Engineering is not simply about writing correct code. It is about weighing competing requirements, designing for maintainability, balancing performance with cost, and coordinating teams that bring a project to life. It is about debugging ambiguous failures and making judgment calls where no amount of pattern matching can substitute for lived experience.

AI will not replace human engineers unless it can perform across this full spectrum. That means more than passing coding tests or solving toy problems. It means the ability to reason through systems, handle ambiguity, and carry responsibility for outcomes. Until AI can do that better than humans, engineers will remain not only relevant but indispensable.

TIL: Pareidolia vs Apophenia

2025-02-12T15:14:00.001-07:00

Pareidolia and apophenia are two big words that both describe our brain’s habit of seeing patterns where none exist. They sound alike, and they overlap, but they are not the same.

Pareidolia is sensory. It is when you see or hear something familiar in random noise. A face in the clouds. A figure in tree bark. A voice hidden in static. Our brains are wired to recognize shapes, especially faces, so they over-apply that skill even when there is nothing there.

Apophenia is broader. It is when we connect unrelated dots and decide they form a picture. A lucky shirt “causing” a team to win. A string of coincidences that feel like fate. Stock market moves treated like signs of destiny. It is not just about what we see or hear, but how we interpret events and weave them into a story.

In short: pareidolia is faces in clouds. Apophenia is meaning in chance. One is about perception, the other about interpretation. Both remind us that our minds are pattern-making machines, sometimes too eager for their own good.

Is AI really a Mind?

2023-03-29T09:24:00.006-06:00

Just a dab of thinking on Artificial Intelligence and Reality.

If we attempt to decompose the human mind into categories and properties, we get obvious members like language, creativity, understanding, synthesis, reasoning, knowledge, and many more. However, this is like defining “what is an elephant?” from a high-definition, three-dimensional hologram. We get members like trunk, head, body, legs, and skin, maybe even respiration, movement, and instinct.

But even if we made the hologram much more detailed, we still could not decompose an elephant exhaustively with observations alone. What we miss is what is inside, not just the organs but how hidden systems work on the macro, micro, and even quantum scales. And we miss those enigmatic and inimitable things like consciousness and simply “being alive.” We might conclude an elephant is alive, but that does not properly capture what it means to be alive and what makes it alive. In other words, there are qualities of an elephant, critical qualities, which we recognize are present but cannot measure or properly observe, regardless of effort or scientific precision.

This matters because if we reassemble our observations in an attempt to create an elephant, the resulting facsimile will not be an elephant. It would lack those added things we cannot measure. Yet if we qualify this new golem using only our meager observations, we could confidently and wrongly conclude, “this is an elephant.” And we would say it while inherently knowing it is not so.

The same problem exists when we decompose the human mind. We have large and small categories that, like the observations of the elephant, define the mind in ways that are nonrepresentational of the subject. And like making an elephant, if we reassemble our categories of the mind into some new creation, we might say, “this is a mind,” while knowing our very words fall inanely short of the truth.

But this is exactly what we do with AI. We observe the qualities of AI and map them to the categories we have made of the mind. We then observe, “AI has the qualities of the mind,” and leap to the false conclusion that this assembly of categories somehow is a mind.

The very misstep we make in concluding “this is an elephant” we repeat with AI. Is it a mind? Is it alive? Is it conscious? Does it think? Or are we too easily ascribing higher-order, ethereal, and foundational qualities to a thing that demonstrates only the simpler, perfunctory, and easily measurable attributes of the human mind?

Is any AI a mind? Yes, but only in the same lacking sense that an airplane is a bird, or a car is a horse, or a painting is really a mountain. If it simulates the broad qualities of a mind, we might conclude it is a mind. But is AI a mind, a real, thinking, living, and conscious mind? Yes, but only in the silliest sense.

So, then, I cannot help but wonder why we are so willing to make this frequent mischaracterization. Are we just victims of fiction writers or clickbait titles? Or is there something else that makes us want to see more where there is actually less? I do not know.

Waiting for Kestral

2022-10-25T15:28:00.008-06:00

Kestrel is the ASP.NET Core web server. You can call its endpoints only after it has started. Using the IHostApplicationLifetime interface, you can register a callback for when the server starts & stops. This prevents workarounds like Wait() or Sleep() or Delay() that, honestly, we have all tried. The callback is nice and clean and is deterministic and reliable.

Let's look at the IHostApplicationLifetime interface.

The IHostApplicationLifetime service is available to you from the service provider. Once you have it you register callbacks to call the host without fear the server is not yet ready.

Knowing you can get IHostApplicationLifetime from the services collection is useful, but if you have local access to the WebApplicationinstance, you can access the same from the Lifetime property.

For a demo hosting and calling a minimal API from a single project - this is nice. But in the real world, access to the local instance of WebApplication is unlikely. In those cases, solve it with a retry policy.

Best of luck!

Triple Edge Constraints in Graph DBs

2022-01-31T16:48:00.001-07:00

What is an Edge? Good question. An Edge defines the relationship between two Nodes. A Node is a thing, noun, or concept – like Store. In my diagram below, the Wants Edge in between the Store and Product Nodes. You would write it as Store–(Wants)->Product and it means to define which Store Wants which Product.

The puzzle here is the Must_Use Edge. In my diagram below, this Edge is between Store and Warehouse and it means to define which Warehouse a Store can use when ordering certain Products. This is special because it references three Nodes: Store, Warehouse and Product. To make this work, the Must_Use Edge must include a field referencing the relevant Product Id.

Adding this value is easy, but it means the Edge rows multiply by the number of Products in the catalog – and with some businesses that can mean hundreds of thousands of products. It also introduces a kind of inferred relationship that doesn’t have a standard representation when drawing a Graph. In the diagram below, I indicate the special relationship in red.

How to maintain high performance with this pattern?

This is a worthwhile question because with so many more rows there is a potential impact. Here are the three things you can do to help:

Add a Unique Clustered Index on Edge($from_id, $to_id)
Add an Unclustered Index on Edge(ProductId)
Add an Unclustered Index on Node(ProductId)

I want to say one quick thing about #1 in the list above, that is to add a Unique Clustered Index on the To/From columns of the Edge. Why do that? Developers might intuit that SQL Graph automatically adds this index on every Edge but it does not. It is an important Index to add to every single Edge, not just Edges in this unique scenario. Good tip!

---

CODE SAMPLE. Here’s the Gist.

---

Scenario

Every Store (wants) every Product
Every Warehouse (Has) every Product
Stores (Must_Use) certain Warehouses for certain Products.

Problem

A graph Edge only references two Nodes: from & to
How can we constrain an Edge to a third Node (Product)

Solution

Add ProductId to Product Node
Add ProductId to (Must_Use) Edge

Considerations

What if there are thousands of Stores, Hundreds of Warehouses, and Hundreds of Thousands of Products? The number of (Must_Use) Edge rows would be like # of Stores x # of Warehouses x # of Products. This could make the edge have millions of rows. With performance as a consideration, is this the only way? Answer: Yes, I think it is.

An Introduction to SQL Graph

2021-04-28T16:50:00.001-06:00

Sometimes the easiest way to learn a new technology is to compare it to a technology you already know. Such is the case with Graph databases. When you hear about them or watch videos about them elsewhere they talk as if they can cure cancer and give you a foot massage all at the same time.

In an academic setting, graph databases can do some fun & esoteric things. But in the real world, where greenfield may never be on the menu, a hybrid RDBMS & graph makes far more sense. Letting the relational system do its thing while tapping into the value & capabilities of a graph in bite-sized chunks without any need for full adoption, big migrations, or system concessions.

Getting started

To that end, I have written a small sample that solves the same problem using relational tables (the part you probably already understand) and then graph tables using SQL graph. A kind of Rosetta Stone for graph databases in terms SQL developers can understand. The solution using tables.

The solution using graph.

What is the common question, you ask? It is to design a system which stores enough data on customers, products, sales, and recommendations to provide to a customer a recommendation of a new products. I know it seems simple, but a complicated sample sort of messes up the whole point of the exercise.

Find the code here: graph.ipynb (github.com)

A list of online tools I use

2021-04-28T16:34:00.001-06:00

Every developer has their list of tools. That list of things making me more productive. That list of things helping me remember, too. Today, I went through my list for my team & thought I would share. Who knows what my list will look like in another 3 or 4 years. Maybe no change at all. Who knows.

.NET tinkering https://dotnetfiddle.net/
HTML/CSS/JS tinkering https://jsfiddle.net/
TSQL tinkering http://sqlfiddle.com/
TSQL linting https://poorsql.com/
Mermaid graphs https://mermaid-js.github.io/mermaid-live-editor
Snippets store https://gist.github.com
JWT decoder https://jwt.ms/
Validate YAML https://freedevtools.net/yaml.html
Beautify JSON https://jsonformatter.tool-kit.dev/
Beautify CSS https://www.cleancss.com/css-beautify/
Regular expressions https://regex101.com/
Color tinkering https://color.cloudflare.design/ & https://color.adobe.com/create/color-wheel
Accessibility tester https://www.webaccessibility.com/
Fake data generator https://lipsum.com/
Image tinkering https://pixlr.com/x/
CSS generator http://css3generator.com/
Chart tinkering https://app.diagrams.net/
Online brainstorming https://whiteboard.microsoft.com/
Json mapping to classes https://json2csharp.com/
Azure icons https://iconcloud.design/browse/Azure%20Icons
QR Code generator https://tools.fromdev.com/qr-code-generator.html
Online distractions https://www.kobayashimaru.com/

Utility scripts for SQL tables

2021-04-28T16:30:00.001-06:00

The SQL Server sys.tables & sys.schemas tables are exceptionally handy to find & filter tables in the database. Quickly looping through a list of table commands to execute a delete, truncate, drop, update, disable constraint, enable constraint, or require data script is easy – just use a while loop, a cursor, or print the results to use in a larger script you are writing. Truth is, this little snippet helps you query for the tables, their schema and the boilerplate script syntax. I’ve used scripts just like this for years.

Here it is on GitHub: link.

An Assert Schema for SQL Server

2021-03-23T11:36:00.001-06:00

In C#, we use Assert to make a claim and to do a few utility operations. For example, we use Assert.Equal(one, two) to claim that one and two have the same values. If this is not true, Assert.Equal() throws an exception that is typically used by Unit Test runners to highlight failing tests.

But in SQL Server, there is no Unit Test framework or runner. That doesn’t mean we can’t have similar behaviors to Assert in TSQL. We just have to write them ourselves. To that end, I have created a starter set of scripts to introduce Assert to SQL Server for database developers.

You can find it here: An Assert Schema for SQL Server (github.com)

EXEC Assert.Contain fragment, string, [message];

Use Contain to validate a string fragment is inside a larger string.

fragment: the string you want to find
string: the string you are searching in
[message]: (optional/default=null)

Syntax

DECLARE @fragment VARCHAR(50) = 'Jerry';
DECLARE @string VARCHAR(50) = 'Jerry Nixon';
EXEC Assert.Contain @fragment, @string;

Result
An error is thrown if the fragment is not found.

EXEC Assert.Equal expected, actual, [message];

Use Equal to validate two values are the same.

expected: the expected value
actual: the actual value
message: (optional/default=null)

Syntax

DECLARE @expected VARCHAR(50) = 'Jerry';
DECLARE @actual VARCHAR(50) = 'Jerry';
EXEC Assert.Equal @expected, @actual;

Result
An error is thrown if the two values are not Equal

SELECT Assert.Equals(expected, actual, message);

Use Equals to validate two values are the same. Because it can be used in a SELECT, it returns ACTUAL.

expected: the expected value
actual: the actual value
message: (optional/default=null)

Syntax

SELECT Assert.Equals('Jerry', NAME_COLUMN, 'Name should equal Jerry') AS NAME_COLUMN 
FROM USERS

Result
An error is thrown if the two values are not Equal.
And Actual is returned if the two values are Equal.

EXEC Assert.NotEqual expected, actual, [message];

Use NotEqual to validate two values are not t6he same.

expected: the expected value
actual: the actual value
message: (optional/default=null)

Syntax

DECLARE @expected VARCHAR(50) = 'Jerry';
DECLARE @actual VARCHAR(50) = 'Nixon';
EXEC Assert.NotEqual @expected, @actual;

Result
An error is thrown if the two values are Equal.

EXEC Assert.[Null] actual, [message];

Use [Null] to validate a value is null. Note that [square brackets] are required since Null is a reserved word.

actual: the actual value that should be null
message: (optional/default=null)

Syntax

DECLARE @actual VARCHAR(50) = NULL;
EXEC Assert.[Null] @actual;

Result
An error is thrown if the value is not null

EXEC Assert.NotNull actual, [message];

Use NotNull to validate a value is not null.

actual: the actual value that should not be null
message: (optional/default=null)

Syntax

DECLARE @actual VARCHAR(50) = 'Nixon';
EXEC Assert.NotNull @actual;

Result
An error is thrown if the value is null

EXEC Assert.Rows expected, [message];

Use Rows to validate an operation impacts a certain number of rows.

expected: the expected number of rows returned
message: (optional/default=null)

Syntax

SELECT * FROM TABLE
DECLARE @expected INT = 10;
EXEC Assert.Rows @expected;

Result
An error is thrown if the resulting rows do to equal the expected

EXEC Assert.Fail expected, actual, message, [number];

Use Fail to manually cause a failure. Note that this is typically used by the other methods, internally.

expected: the expected value to report
actual: the actual value to report
message: the custom message to report
number: (optional/default=50000)

Syntax

DECLARE @expected VARCHAR(50) = 'Jerry'
DECLARE @actual VARCHAR(50) = 'Nixon'
DECLARE @message VARCHAR(50) = 'Error Message'
EXEC Assert.Fail @expected, @actual, @message;

Result
An error is thrown. Every time.

EXEC Assert.Error [number], [contains], [message];

Use Error to validate an error occurred with expected values.

number: (optional/default=do not test): the expected error number.
contains: (optional/default=do not test): the expected error message fragment.
message: (optional/default=null)

Syntax

BEGIN TRY
  /* YOUR WORK */
END
BEGIN CATCH
  DECLARE @number INT = 50000
  DECLARE @contains VARCHAR(50) = 'DATA TYPE'
  EXEC Assert.Error @number, @contains;
END

Result
An error is thrown if the current error context does not meet the criteria

EXEC Assert.[PrintLine] message, [withdate];

Use PrintLine to simply print a message. Note that this prints with NOWAIT even when SQL server is actively processing.

message: the string to print/output
withdate: (optional/default=true)

Syntax

DECLARE @message VARCHAR(50) = 'Jerry Nixon';
EXEC Assert.PrintLine @message;

Result
A string is written to console.

A Kickstarter for features: It’s a Better kind of User Voice

2019-03-16T16:30:00.001-06:00

For decades, I’ve watched users and developers long for capabilities in Windows and .NET that never happen. Sites like Connect and User Voice collect our ideas and votes yet backlogs rarely react.

I believe product teams often chase the next big feature, forcing themselves to ignore small, love-creating improvements or tweaks that would build tireless loyalty from their user base.

For this reason, I would like to propose a new idea. A way to solicit, not feedback, but ideas from a user or developer community in a way that gets results and creates wonder.

What’s wrong with User Voice?

This isn’t about User Voice, per se. The site’s fine. It’s about the reaching into a product team and impacting their backlog. Giving great ideas a social momentum that gets recognized as valuable.

We know up-voting ideas for Visual Studio, .NET, Windows, or anything else barely matters. I’m not being cynical but go look – the list of outstanding ideas is astronomical. But, it’s reasonable.

Team capacity. There are only so many product managers and so many engineers on any team. Their capacity to do anything has a real limit; asking for the moon is sometimes simply impossible.

Team priorities. There are roadmaps follow and next versions to build. Sometimes the best ideas simply don’t align with where a product is going; asking for THAT features just doesn’t work.

Team turnover. There is velocity-crippling turnover to consider. People move on, change happens, and the team might be rebuilding itself; asking for anything is crazy, just staying afloat is job one.

Internal politics. There are many things far outside the control of a product team. Reorganizations, changes in corporate priorities; asking for something might simply be impossible, considering.

Market change. There’s a real need to survive. Sometimes companies like Microsoft over-correct and create a brand-new problem; asking for something in this environment can be a stalemate.

In the end, outside developers and users of a product are important but are also a single voice in a chorus of influences pushing on the priorities of a product team. That’s just reality.

Side-effects

The rise of open source, if you ask me, is, in part because of this. Developers frustrated with expressing desires (to Microsoft) and not seeing an acceptable response, took things into their own hands.

The rise of more-frequent product releases is another. Product teams aching to deliver functionality to their community but hamstrung by larger constraints found a workaround, for better or worse.

It’s also worth pointing out that, especially in developer tooling, buckets of features are released every quarter as a direct result of user feedback. But nobody is denying features are left on the table.

Impacting priority

We can’t change capacity. We can’t change reality. But we can change priority – most of the time. This idea is rooted in a social contract with Microsoft agreeing: if the community does X, the team will do Y.

I assume you know what Kickstarter is. That side where someone with an idea gets socially funded; a grass roots approach bypassing traditional channels to get innovations and inventions realized.

Now imagine this: a site like Kickstarter for features. Where users or developers contribute to the feature with real money, pushing toward a target that, if reached, the product team agrees to deliver.

Where does the money go? Not to Microsoft. Every feature is a fund-raiser for a charity. If we raise $100,000 for breast cancer research, we’ll add a Purple Theme to Visual Studio. See what I mean?

Here’s another one: We’ll make Windows Forms work on Macs if we raise $250,000 for Doctors without Borders. Teams can target timely charities, too. The point is, it’s a social agreement to do it.

Why would a product team do this? Because corporate citizenship is real. Because diversity and inclusiveness matter to Microsoft. Because, doing something good is a true motivator.

How much would a developer have to contribute? That’s the beauty of this. If you contribute a single dollar, you’re a contributor. Visual Studio has nearly 5 million users a month. This is possible.

Let’s all agree on one more thing. Software developers are not the lowest paid people on the planet. And why not do some good instead of complaining on Twitter? It’s twice the reward.

Well, do you think it could work?

Developer Evangelism’s Obvious Secret

2019-03-13T15:55:00.002-06:00

Hi. So, here’s another entry from my notes as an Evangelist. Many of the snippets I once wrote to myself I have now translated into blog articles that I hope will help anyone who finds themselves where I once was. This one is about the role of empathy. Perhaps it is not as obvious as you assume.

For the sake of argument, and I think that is reason enough, let’s treat Developer Evangelist, Technical Evangelist, Developer Advocate, and any other variation of a Developer Relations title as the same. For the most part, they are. Here, I will use Developer Evangelist, since that was my title for nearly a decade at Microsoft. And I like it.

What is an evangelist?

Let’s start with a simple question that has a complicated answer: what is a Developer Evangelist? Hopefully, you start with “brand ambassador.” Like a garrison at the edge of the empire that represents the throne because the king or queen will never travel that far, you are the brand.

If you work as a Developer Evangelist for Acme, your role is to represent Acme to developers who would otherwise never connect with Acme. For this reason, being “on message” is critical. For this reason, the theater of evangelism is important, and playing your role is imperative. In a way, you are not you.

This is the foundation, but it is not the most important part. Building rapport and influence with developers and their communities requires connecting in ways that go beyond being a walking blog. The hearts and minds of developers are your endgame. The strategies to reach that goal are what matter.

Give it all away

The first tool in a Developer Evangelist’s toolbox is swag. I have a love-hate relationship with swag. On the one hand, I love seeing an audience’s eyes brighten when you give them something that has little value but somehow means a lot to them. My favorite swag is baseball hats.

The problem with swag, of course, is that it triggers the pleasure centers of a developer’s brain but does not build a long-term connection. Give me your thing and I will go to the next person for theirs. It ends quickly, even if you complicate it with surveys or games.

If I had my way, I would give swag only to developers who are already my friends, already in my camp, already onboard. A sort of reward-swag, not a bribe-swag. You will notice the difference immediately in gratitude, and your swag might even get some use before it ends up in a trashcan or thrift shop.

The three other things

If swag does not reach the hearts and minds of developers, what does? A Developer Evangelist has three real tools: Information, Validation, and Prescription. These are what truly influence behavior.

Information. It is getting harder to keep up with the pace of our industry. A Developer Evangelist has inside information that is unique and difficult to otherwise find. Bringing that value to developers means giving them something they could not easily discover or piece together on their own. This is also a key way to get your talks accepted at conferences. Bringing unusual or overlooked information is compelling to both attendees and organizers.

Validation. Developers and architects are often suspicious of their own decisions. As someone with more information than most, you can provide validation. Affirming their work builds trust and affection. When you find a developer doing something “wrong,” balance reproach with respect. You will leave tomorrow, but they remain in that job, with that manager, working for that raise. Your role is to advocate for developers, not fuel their imposter syndrome. They will love you for it. You also carry some responsibility to make sure customers are on a correct path with your technology. First earn the right to speak into their work, then guide carefully.

Prescription. Many developers are happy to figure things out, but they love prescriptive guidance that helps them avoid the “dumb tax.” Your value is in showing how to get started and where to go next. Sometimes this comes in case studies, sometimes in made-up scenarios, sometimes in tutorials or white papers, sometimes in personal journeys you have documented.

Empathy

This is where empathy comes in. Understanding where a developer is on this scale is difficult. A kind of cold reading becomes part of personal interaction, even when reading an audience from a stage. It is a mind-meld at scale. Changing your tone and intent on the fly is an important ingredient in successful Developer Evangelism.

Remember, empathy is your ability to understand or feel another person’s emotional state. Sympathy, on the other hand, is responding to that state. I am not suggesting a Developer Evangelist must have sympathy, though it never hurts, but empathy is essential.

One of the most powerful ways to build empathy for developers is to live their life. Walk a mile in their shoes. If you wonder what a developer experiences when using your product, start from scratch and document every single step. It is eye-opening.

Another exercise is inclusive design. To understand how users feel when they cannot see, try using your application with the monitor turned off. See how far you get. That, too, is eye-opening.

The magic

Communicating empathy is like magic. Saying things like, “I know what you mean. The portal tells you to do it this way, but it never works, does it?” is not betraying your product; it is empathizing. It is the kind of warm rain everyone relates to.

It is worth pointing out, however, that you can easily betray your product. Saying, “Yeah, it’s not stable,” or “I’m sick of all these bugs, just like you,” can crush confidence in a product and create distrust. You might feel like you are being real with your audience, but you are laying a foundation of doubt.

Here’s the takeaway: most developers are struggling. When you catch yourself thinking, “It’s not that hard,” or “Just use the docs,” you may be falling into the same trap as a Stack Overflow moderator. You are forgetting that every developer is at a different place. Your job is not to prod them to work harder but to encourage them toward hope and to make their lives better and easier today.

Find ways to look at developers with empathy, with a compassion that helps you slow down, present 101 instead of 401 sessions, re-explain a concept you have already explained a thousand times, and look forward to their success, not yours.

Three Reasons for Developer Evangelists to Engage

2019-03-04T14:57:00.001-07:00

I would like to talk about the reasons for a Developer Evangelist to engage an audience. We already understand the three ways we can engage: online, personal, and onstage.

As a reminder, online engagement has the greatest reach but the least impact, personal engagement has the greatest impact but the least reach, and onstage engagement is a combination of the two with varying results depending on skill, style, and approach.

But as you prepare your talk, ask yourself why. Why are you engaging in the first place? As you are driving to a conference or meetup, ask yourself again: why are you engaging? I would assert there are three reasons for Developer Evangelism engagement.

When it comes to persuasion or public speaking, there is only one reason for engagement. Developer Evangelism is a specialized engagement strategy that uses persuasion or public speaking as a vehicle. Where public speaking aims at changed behavior, Developer Evangelism is more nuanced.

Here’s the list

It is fine to oversimplify at this point. Developer Evangelists engage audiences to either 1) introduce, 2) educate, or 3) inspire. It is not practical to approach any engagement with the goal of accomplishing all three. It is, however, reasonable to span more than one with some planning.

Introduce. One of the most common tasks of Developer Evangelism is to get the word out. Companies with new products rely on these boots on the ground to bring awareness of those products to the right communities. This is where breadth matters, not depth.

In this phase, the assumption is that most of your audience has no idea what you are about to say. The topics are targeted and simple, with outcomes measured by interest, awareness, and possibly registration. This can mean hard work, a lot of travel, and a large online investment.

On the whole, this is a basic use case for a Developer Evangelism team. It often signals short-sighted leadership chasing metrics that are usually artificial, changing, or unimportant. It is an acceptable place to start, but no team should consider this their destination. It is only warming the engines.

Educate. Another common task of Developer Evangelism is spreading understanding. The effort applied here is directly related to the quality of available documentation. In place of excellent examples, tutorials, and docs, Developer Evangelism fills the gaps with education-oriented content.

The biggest problem with this aspect is that education is time-consuming, mundane, and distracting from bigger, better strategies. It usually results in articles and sessions that require significant preparation yet are seen by only a few.

Developer Evangelists are overqualified to impact the effectiveness of documentation, but their involvement is very important. They are not always the best technical writers or tutorial authors, though they can be. Still, the goal is to move beyond this strategy quickly. Get it over with.

Inspire. The highest form of Developer Evangelism is to present developers with a prototype of what they could become later in their career or later in a project’s cycle. Inspiration says, “I understand where you are” and then asks, “Can you imagine where you could be?”

These engagements span technologies, products, and communities. They are relevant because they speak to the “why” before the “how.” They elevate a developer from technical leadership to thought leadership, making the Evangelist’s message a secondary win.

What do I mean? This is simple, yet elusive. Developer Evangelism is often explained as recognizing where a developer is in their personal journey, meeting them there, and helping them succeed. That is noble, but it is also too small and too shallow a vision.

As a Developer Evangelist, if you only attach to a developer’s current situation, you limit your own opportunity to succeed. We want to understand where developers are so we can talk with them, but the reason we talk to them is different. We talk to them to change their journey.

Inspiration is the power to cast vision into someone else’s life. Yes, life. My goal is to change your college major. My goal is to change your career goals. My goal is to change your behavior and your habits. Unless you and I are already aligned, then my goal is simply to encourage you where you are.

Novice Developer Evangelists chase “awareness.” Great Developer Evangelists can get stuck filling the gap of poor documentation. But when we stop at “Hello World,” when we stop teaching class, we miss the chance to challenge developers to be more. No Developer Evangelist needs to fight for attention at that level.

How do you get there? It is easy. Stop and ask yourself why you are about to engage. Is it because you are chasing awareness? Awareness is not important to the developer. Is it because you are trying to teach an approach? Developers have libraries of blogs for that. You need to refine your intent.

You must find goals that matter to developers without making yourself captive to their tactical needs.

Engage to change. Engage to improve. Engage to inspire. And inspiration begins with vision casting, the ability to paint a picture of something that is not yet real but could be, then challenge someone in a realistic way to pursue that vision, that shared vision you have created.

Let developers reframe your vision as theirs. Then show them the tools that can help them achieve it.

Intentional engagement is powerful, and in the end, everyone wins. Give them a fish, teach them to fish, or show them a picture of a fishing boat and inspire them to learn sailing and seafaring. Do not stop with today when you should be showing them tomorrow.

Best of luck.

Some goals for 2019

2019-01-01T13:34:00.001-07:00

Hi. Today is the first day of 2019; I have a few goals for the coming year I will codify here so I can look back and see how I did. This is not a list for you, it’s for me. That said, I am satisfied for my list to influence your list, should it.

I have some big things afoot in my life and should waters stay smooth, these goals are both attainable and what I want. I should also point out this year’s goals resemble last year’s goals. I am certainly a creature of habit. Some of last year’s goals were reached. Some are carrying over. Some, however, always make my list in one form or another.

1. Re-watch Battlestar Galactica 2004

I am starting with a goal I have been wanting to do and likely will, regardless. Previously, I binge-watched the series with this rule: I can only watch the show if I am on my treadmill. I calculated nearly 400 miles by the finalé. I have forgotten the B storylines and should relish in, what I think is science fiction’s high-water mark. Star Trek is a wonderful universe, but Battlestar Galactica 2004 is the finest show science fiction fans have been given.

2. Read the seven Harry Potter books

It might seem impossible, but I have neither read the books nor seen the movies. It’s just one of those things. It’s been my intention to do both for some time; if for no other reason then to get the pop culture references that certainly go over my head today. So many friends adore them, I am surprised I have managed to wait this long. We’ll see if I get my own wand and plan a pilgrimage to Harry Potter world at Universal.

3. Write twelve blog articles

Once again, I am looking for attainable goals – after this article, I only need eleven more. It aligns with one article a month, and it’s more about writing and expression than anything else. Don’t expect only code walk-through articles, either. Why blogging has been declining is a matter of debate. I know mine has. But it’s great, helping me remember what I discover. I’m pleased to turn this back on.

4. Pay for what I Torrent

We’re treading on an ethical issue for me. There are times when a Torrent of a movie or television show is not wrong. Not to me. For example, Star Trek Discovery launched only through CBS All Access. I signed up. But the CBS service and app were so bad, I had to torrent episodes to watch them without buffering. What did I do that was wrong? Nothing. Not to me.

When I Torrent movies, for similar technical reasons, I turn around and rent them (later) from Microsoft Movies or Amazon Video. I’ll Torrent Netflix movies just the same, but I subscribe. Is it weird to Torrent movies and still pay for them? No. Not to me. There are two roads: a low road and a high road. This goal is less something I want to do in 2019 and more something I want to keep doing in 2019.

5. Write the "Difference Between" draft

I’ve wanted to write a book for decades. So many novel ideas later, I’ve never written more than an outline and a few chapters. Difference Between is my latest, but it’s not a novel; it’s an etymology book addressing terms regularly misused in writing and speech. For example, Fate & Destiny or Hard & Difficult – terms we treat as synonyms, but they are not.

The draft will be difficult, not hard. ;-)

6. Publish my Star Trek Dreams Alexa skill

White noise is a staple at the Nixon house. My kids sleep to it, as do my wife and me. We don’t live near a highway, a train track, an airport, or a draw bridge. We live in the mountains – it is blisteringly quiet and white noise helps us sleep through strong winds or woodpeckers drilling into the siding. Star Trek Dreams is white noise, Star Trek-style. Version one is simply the TNG warp core gently beating all night. It's really for me. I see that.

7. Read 48 books

That’s four a month. It should be easy. My Harry Potter goal checks off seven. I love reading. Audio books are an easy way to shorten a long flight or drive. I love underlining in books and just holding them. I like philosophy books but not self-help; I like memoirs but not biographies; I love post-apocalyptic but not horror; I like science-fiction but not fantasy. And, I can tolerate history.

I’m not all that picky. Not really.

Here is my reading list from November and December 2018:

One Year After & The Last Man by William R. Forstchen. These are the second & third books in the One Second After series. They started my ongoing love for post-apocalyptic novels years ago. There are no zombies. This is about how society survives without the internet, cell phones, and electricity.

Master of Formalities by Scott Meyer. This galactic-scale science fiction novel follows the odd events around a century-old cold war between feuding kingdoms. It’s very long, but quite creative. It’s a wonderful treatment around the subtle use of language to control those around you.

God is the Gospel by John Piper. Books challenging contemporary norms are my cup of tea. This book asks the question: “Could you be happy in heaven if Christ were not there?” It’s heavy. I stop about every chapter and just think about it a little. That’s what I like. Having to think.

You are not so smart by David McRaney. This book is a lot like Do Gentlemen really prefer blonds by Jena Pincott. They are fascinating evolutionary biology studies. They make for interesting conversation. I also think these books give me an advantage when dealing with people. It almost feels like cheating.

The Dispatcher by John Scalzi. This audio book was narrated by Zachary Quinto, who I like. In the future, inexplicably, anyone intentionally killed wakes up fine in their home. The Dispatcher is responsible to intentionally kill anyone dying any other way – like in surgery. It’s a short story. It was weird. I liked it.

Neverwhere by Neil Gaiman. This is a fantasy book. I hate fantasy. This florid novel fell into my stack of books, so I read it anyway; I found myself surprised at how interesting and imaginative the story was. It basically followed the enigmatic, secret world under London & invisible to us normal mortals.

The Long Haul by Finn Murphy. This might be the best book I read in 2018. It follows the life story of a trucker whose thoughtful prose massively educated me on this opaque field with hilarious anecdotes. I still talk about this book all the time, and constantly looked forward to reading the next chapter.

Love Does by Bob Goff. My wife read this book a few years back, so I felt I should, too. I am glad I did. It iterates the funny mishaps of a guy who retrospectively finds the meaning he couldn’t see at the time. It’s difficult to believe this many crazy things can happen to one person – and he would still be alive.

The Sherlockian by Graham Moore. This blends two stories into one: one is a story from the life of Arthur Conan Doyle, the other is a contemporary mystery investigated by a Sherlock Holmes enthusiast.

House of Suns by Alastair Reynolds. This is my kind of science fiction. A family of immortal clones observe the galaxy, getting together every 200,000 years to compare notes. Then something changes.

I suck at girls by Justin Halpern, the guy who created S#!t my dad says. It’s Halpern’s coming of age memoirs with frequent insights from his dad. It’s tragically funny. I found myself looking forward to the occasions he would interact with his dad and skimming his own personal story. I laughed.

8. Rewrite Free Timer in the Microsoft Store

I get two or three emails every week from Free Timer users. They are asking for new features that would be simple to add if I had not lost the source. ;-) It’s crazy how many people use this app. I have not updated it since Windows 8. It’s time. The interface is wonderful, but it looks just a little dated. I want to make it better and use the effort to sharpen any of my UWP skills that may have dulled.

If I manage to get that updated, I’ll follow up with writing my Pomodoro app. It’s a powerful technique to focus and I’ve been wanting to write the app using the Desktop Bridge for a year. But, it’s one app at a time – Free Timer comes first. The Pomodoro app will exercise my Xamarin certification that’s just gathering dust while I spend most of my days writing bot and edge libraries. Should be fun.

9. Dial back on the caffeine

When my doctor prescribes a drug, I hate it. I resist vitamins, supplements, even medicines for coughs and colds. It’s just my thing. I eat well and maintain a pretty healthy balance. Yet, I seem to look right past caffeine as a drug. It is. The amount of caffeine I consume might be less or more than what you consume, I don’t care; I’m ready to change my consumption habits.

My goal for 2019 is to change my caffeine consumption to the point where this goal (or anything like it) does not show up for 2020.

10. Leave room

Because I have OCD tendencies, I am tempted to make this an even ten goals. But I am not, except to say this: I’ve rarely felt constrained by rules and I don’t want to be. It’s important for there to be order and consistency in life, but it’s equally important to leave room for change and the unexpected. I want to leave margin to not rush as I go or justify compromises in order to check a box. I’ll get done what I can, but the prime directive, rule zero, is to live. I don’t mind regrets, but I don’t want to add any new ones.

And so, we open 2019. Some of these goals are lofty. Some of them are silly. But they are all real, for me. And sitting here in January, this is what comes to me. This is what I want to see in this coming year. It will be interesting to see how these change as the months pass. Meanwhile, I will do what I can.

Happy new year.

PS: I have some technical goals like learning Python and F#, but I am not adding them to the list. I have some personal goals like exercise and eating, but I am not adding them to the list. These seem a little too cliché and I didn’t want to create a cliché list of goals for 2019. I wanted to create this list.

The three pillars of Technical Evangelism

2018-02-08T18:42:00.000-07:00

Terms like evangelism are funny. Etymogically, evangelism is about converting and teaching. Where most of us are used to hearing it in the context of theology, technical evangelism is about teaching and converting in the context of technology, most usually software development.

I am a Microsoft Evangelist. It’s my real title, and I sometimes must show people my card before they believe me. As a Microsoft Evangelist I am converting developers to Microsoft Technologies. I also teach, of course, but it is a fundamental part of evangelism that teaching, though important, is secondary.

Consider the haters. Every software developer has preferences, but some idealize their own preferences while vilifying every other. But that’s not the end of the story. That’s only the setup. You see, when it comes to people, Evangelism is a secret weapon.

What isn’t evangelism?

Evangelism isn’t when I go speak at conferences. I do go speak at conferences, though; it extends my reach into professionals. Evangelism isn’t when I go speak at schools. I do go speak at schools, though; it extends my reach into curriculum. Evangelism isn’t when I run a booth at a science fair. I do run booths at science fairs, though: it extends my reach into students.

Speaking is important, yes, but it isn’t Evangelism – at least not core evangelism.

There’s only one proven way to change the heart of a hater. There’s only one proven way to influence the technical choice of a professional. There’s only one proven way to change the major of a student. That is: meet them. That’s because there is some wonder-working power in personal interaction.

I get in my car and I go to where they are. They will never come to me. They will never read my documentation, my blog, or follow me on Twitter. They hate Microsoft, and, to them, I am Microsoft. Worst yet, each hater is an anti-evangelist, bloviating their opinion to whoever listens, personally.

They are not who you think.

Who are they? Well, haters surprise me. They are often the most generous and contributing members of the development community: meetup organizers, event speakers, even conference volunteers. The reason they feel the way they do, the depth they do is unique to each one. But it’s generally somewhere between some negative experience and a lack of direct exposure to the technology.

Before you start, set in your mind the truth: First, they aren’t bad, they just have an opinion. Second, they don’t hate you, they don’t even hate the company, they hate the idea of it. And, third, you might not change their mind. That last one is a rough one in our metrics-driven, corporate reality.

A quick intervention goes something like this: a hater might hate Microsoft, but do they hate Jerry (that’s me), right? Look, man, I’m just a guy. Like you. I’m trying to be a good husband; I’m trying to be a good dad; I want to do something right and get my mortgage paid each month. Honestly, that usually does it. Putting a face to the faceless profoundly changes perception. Usually, to the better.

Don’t make friends.

Quick aside: I do like making friends. ;-)

My goal is not to make friends. My goal is to lose enemies. Let’s say their mantra today is “Microsoft sucks”. After some mindful attention, if their mantra tomorrow is “Microsoft is okay for some people, but it’s wrong for me”, that’s not just winning a battle, that’s winning the whole freaking war.

It’s like stopping a leak. It impacts decisions. It impacts sentiment. It impacts perception. It impacts adoption. And, honestly, it impacts stock prices. When everyone around you is no longer trying to burn down that bridge, you might just start investigating how to cross over it.

Google has Developer Advocates. Microsoft now has Cloud Developer Advocates. These are good guys. But it’s worth teasing out the difference between Advocates and Evangelists. I sum it up like this. Advocates say: I’ll teach them to use it and hope to make a friend. Evangelists say: I’ll make a friend then teach them to use what I ask them to use. These two are so allied yet so different, it’s crazy.

Make it personal.

For me, it starts in my car. I must drive to get to people. And, if I were completely honest, I don’t always like it. Meetups meet at crazy times. I’m sick of eating so much pizza. Code camps are typically over weekends. I have my own family. But if you don’t go where they are, they will never come to you. Just remember that sometimes a single handshake is the butterfly wing that changes everything.

When it comes to evangelism, it’s easy to dance around burnout. Nobody is going to tell you to take time. Nobody is going to tell you to slow down. And, most of us work from home: nobody is going to tell you to stop working in the middle of the night. That said, time management and some aggressive self-advocacy on your corporate calendar can be what holds the breaking point at bay.

Evangelism is very rewarding, you see. The number of people you meet. The inherent authority you carry with you. Your ability to truly help people. It’s all the right side of how we all want to live. Speaking, mingling, networking – and the real secret is that most evangelists are introverts.

Only influence matters.

The fast-track to influence is inspiration. Sometimes I hear people insist evangelists must be excellent software developers. To be fair, I am a software developer. Sometimes, excellent. Their faulty reasoning usually reads like this: if you don’t have the technical chops then people will not listen to you.

But, have you ever listened to the most junior voice on your team? Even the one without the technical chops? Of course, you have. Can you only learn from a professor? Isn’t the nature of diversity a recognition that every voice has unexpected value? Why would we assume developer audiences are so shallow, are so myopic, and are so ridiculous that they can only hear the words of Nobel prize winners and scholars?

If you have ever been to a meetup, you know the opposite is true. They are the proving ground that lackluster speakers and mediocre developers miraculously impact the hearts and minds of their personal community in measurable ways. Please. I hope you don’t fall into the trap that an evangelist must only be the best of the best. Only influence matters. Influence is a byproduct of inspiration. And inspiration comes from people like us. People we relate to. People who are good. People who may not be great.

Build a team

If I were building a team of evangelists, I would start every interview with one (silent) question about a person: Do I hate them? I mean it. If you couldn’t even go camping with a guy without wanting to kill him, how can we expect him to meaningfully inspire someone into action? The best I could hope for is that nobody would ever get to know him. And, how stupid is that?

Instead, the type of person I am looking for is the magnet. You know the type. At dinner, everyone seems to be asking her all the questions. At the bar, everyone seems to be standing in a circle around him. At the meetup, she’s always got a line of people wanting to ask her a question. These are the magnets. The ones that don’t have to ask to influence others, they are being asked to do it.

Let’s step through a thought experiment: Who is the most likely person to influence you? The person you like the most or the show off who flies in to demo a product? Sometimes, it’s the latter. I know that. But, overall, its your buddy: the one you like, the one you hang out with. If the goal of an evangelist is to change the course of a decision, and it is, then you want an evangelist that can do that.

Here’s a conundrum. What if all the influential people are not engineers? I would never advocate someone who does not know software development to be a Developer Evangelist. That’s lunacy. But I would never set the bar of engineering higher than the bar of magnetism. And, since most software developers have zero or no magnetism (some repel, I think) a great engineer might even be a red flag.

But, what are the three pillars of evangelism?

Honestly, I forgot to get to those. Sort of chased a rabbit there. Next time, I guess. Sorry.

Custom UWP-XAML attached properties

2018-02-03T14:41:00.002-07:00

Look, this article is for me. I keep forgetting the basics of XAML attached properties & some advanced syntax. If this helps you, too, great.

As the author of Template 10 (the best UWP framework) I keep on my UWP toes with XAML & WinRT. I may not be a XAML Jedi, but I’m on the path. You’d think after writing about this in my Navigation View article in MSDN Magazine article last month I would have it all locked in. But, I’m the type of guy who forgets things. Even stuff I mastered just last month. So, here goes.

Containing class

The only requirement for an attached property is that its containing class derive from DependecyObject. The class cannot be static.

Basic property

A simple property holds a strongly-typed value. Every attached property must have a default value set in PropertyMetadata during RegisterAttached.

Constraining to a type

An attached property is, by default, available to every Dependency Object. To limit this, change the signatures of the static Get()/Set() methods.

XAML syntax

After adding a namespace, you can use XAML’s simple and complex property syntax for attached properties. Each have type-safety.

Note: The approach to data binding to attached properties is identical to databinding dependency properties directly on the control. Either syntax is supported.

Setting in Styles

It’s also possible to use style setters. The syntax is nearly the same.

Handling change

The most reliable approach to handling changed values is in the changed handler set in PropertyMetadata. It’s already on the UI thread.

Note: You’ll need to cast both the sender and the e.NewValue (there is also an e.OldValue) to the correct types before you act on them.

Updating controls

Sometimes properties are for updating controls. The constructor has no reference to the controls. Operations must execute during the Set() method.

Setting values in code-behind

Attached properties, like dependency properties are only a property bag, not real properties. As a result, they are stored as [object], not strong-types.

Reading values in code-behind

Reading the value of attached properties is the same as reading dependency properties. And like dependency properties, you need to cast the value.

Enumerable attached properties

Sometimes a scalar value isn’t enough, you want to store an IEnumerable. Attached properties can do this natively: use List.

Important: it is up to you, the developer, to instantiate the list. In the Get() method, check if the value is null. If it is, create it, then return it.

XAML Syntax

It’s simple to add items to an attached property of IEnumerable. The XAML platform understands how to Add() for you, so there’s nothing special.

Note: the simple XAML syntax is not supported here. If you are binding to it, you skip the Get() changes and bind a List, not its items.

Handling list changes

A List does not raise events when it is changed, and the attached property changed event will never raise. You need an ObservableColelction.

That’s it.

Question & Answer

What about that literal string?

Unlike dependency properties, attached properties have no real object or member for to use nameof(). This means that literal string is required.

What do you call the control using the attached property?

According to the Microsoft Docs, that’s referred to as the “owning type”. See here: https://docs.microsoft.com/

Can I iterate through all the owning types?

If on each Set() you store a control reverence in a static List you can, but you have to wait for Set() to be called. Otherwise, no.

Can I put all my attached properties in a remote assembly?

Yep. You can put all of them or some of them. You just need to be able to create the namespace reference in your XAML declaration.

I assume the value is disposed when the owning type is disposed?

That’s what I assume. Yeah.

Are attached properties inherited like dependency properties?

Nope. That's one big difference.

What about the "Cannot add instance of type ObservableCollection" exception?

That means you aren't constructing the list in the Set() method, dummy.

// Best of luck.

A personal review of some Star Trek swag I have lying around.

2017-09-21T11:41:00.001-06:00

I have a few Star Trek things sitting on my desk, in drawers, or around the house. This isn’t really a review as much as it is an excuse for me to talk about them. This is important since the first episode of Star Trek: Discovery is only 3 days away and I am getting anxious about the whole thing. Don’t think of this as a buyer’s guide as much as me, dreaming up an excuse to talk about Star Trek in anticipation of the new show.

The Star Trek Enterprise Pizza Cutter

Four stars. Received it for Father’s Day and can’t stress enough the high quality of the item. It’s solid, shiny, and quite nice. As a pizza cutter, it does the job with one complaint, the saucer section can get gummed up with sauce. It’s a wonderful play on words, but sort of a pain in the neck to clean. Did I send it back, of course not. And, I store it in the cool black box it came in, not with the carrot peeler and paring knives. It feels special when I get it out.

The Star Trek Cast Paying Cards

Three stars. This was an inevitable gift. My nephew gave it to me, actually, buying it at a novelty story when he saw them and thought of me. Good kid. The cards are not Bicycle cards, by which I mean they don’t have the texture or pliability of the industry standard. They are also quite a challenge to scan for number and suit. The pictures are not cast pictures you normally see or might even pick yourself. That being said, they are the deck I take on vacation and we have played many games with them.

The Star Trek Original Commit Blanket

Five stars. This beauty was a birthday present from my girls. I adore the Star Trek comics and have tons of them filling the cracks of the couch even now. This blanket is a cute snippet from those comics and is a perfect color, quality, size, and plush. If this blanket has anything going for it, it’s how wonderfully soft it is. I watch episodes of The Big Bank Theory cuddled in this little luxury. The girls might have given it to me, but they tend to find ways to take it for themselves. And, hey, I can’t blame them.

Star Trek Black Command T-Shirt

Four stars. I am a fan, but sometimes a graphic T is just too much. A shirt like this fits the bill. Any other fan will immediately recognize the delta and even place the movie this shirt was introduced. My shirt arrived with the delta slightly too far left, it’s supposed to line up with the collar bone. I am not picky enough to send it back, so I kept it and will simply give it four stars here.

Spock Crew Socks with Ears

Five stars. Here’s an easy Birthday gift. When I saw these come on sale, I knew it was only a matter of time. My sister-in-law must have a bookmark to Think Geek, because the week before every birthday, a box from them appears at my doorstep. This time, it had the Spock Socks. I was speaking at an event and mentioned I was a fan when a developer in the crowd showed his Trek shirt and asked, “Yeah but are you wearing the shirt?” I was pleased to be able to pull my pants leg and trump him with these beauties.

United Federation of Planets Cuff Links

Five stars. Something borrowed, something new, something borrowed, something Star Trek. It’s classic. I didn’t have these when I got married, but had I, these would have made an appearance. They are stunning, and the subtle Star Trek-factor is pretty small. Most people just they they are ornamental and decorative. The astute recognize that they represent an interstellar federal republic of planetary members. The backbone of the Star Trek universe.

Star Trek Comics, Seatbelt Belt

Five stars. There are a few things in the collection that really stand out. not only does it depict the comics, which I love, but it’s unusual design makes it really stand out from the crowd. It was my go-to belt for nearly a year until I tired of taking it off in the airport. I travel. This sets off every metal detector.

Star Trek Uno

Five Stars. Star Trek Uno is unlike normal Uno. It includes a Beam Me Up card that can get you out of any setup. My girls love it and we’ve played it a thousand times if not two. Uno is already quick, easy and fun – adding a Star Trek theme just makes it even better. We have house rules that let you play a Scotty on a Scotty and a Sulu on a Sulu, etc. It’s a fun variation when your travelling or something. There are actually two versions out there, and we have both. Generally, we prefer the classic version with just the Beam Me Up cards.

The Star Trek Grill Set

One Star. Oh, I wanted this to work. Like most Father’s Days, a Star Trek something-something showed up under the tree (so to speak). Opening this set was a treat, it’s box and presentation is jaw-dropping. But the shape of the flipper, the weak tongs, the awkward fork, only the skewers are nice. When it comes to grilling, I take things seriously and can’t have half-baked equipment. This grilling set is beautiful, but completely useless. For the price, it’s a frustrating reality.

Captain Kirk Grilling Apron

Five Stars. If the grill set let me down, it was all made right by the Captain Kirk apron. A birthday present from my wife, this thing does the job of protecting my uniform from splashes, while ensuring would-be Klingons know who’s who. Even though I wish it were a little more thick, I have to say it’s basically just what I want in an apron – if a man has to wear an apron in the first place.

Star Trek Electric Door Chime

Five Stars. This little chime sits right outside my office. Pressing the little white button produces the boatswain whistle made commonplace by Star Trek and military movies through the ages. It also has a motion detector, but it takes about 5 minutes before you shut that feature off. It’s beautiful, fun, and an anchor aesthetic to our hallways. Had they made it a wireless intercom, well, that would have been near-nirvana. As it is, I just love it.

Tea Earl Grey Hot Mug

Five stars. Nothing kicks off a morning like drinking from an LCARS mug. It turns out that Earl Grey really is the finest hot tea. Most of the people around me certainly assume I say that because of Star Trek, But I really believe it. Drinking Earl Grey from this mug makes it taste even sweeter. If it was good enough for Captain Picard, it is good enough for me. Or something like that. When we clean out our mug collection from time to time, this one is never considered. This one is, special.

TOS Uniform (Science) Bathrobe

Five stars. Here’s a classic. I’ve been wearing this beauty for years now. It’s thick and soft and awesome in a million ways. Since you have to wear a bathrobe anyway – like walking out to the hot tub, making Saturday pancakes, or whatever – why not do it in regulation specs? I’ve about work mine out, to be honest, but it’s the perfect Christmas present. Sure, I could have gotten gold/command colors, but this is Spock’s uniform and I like that most.

Star Trek Catan

Five Stars. Catan is fun. You might not know that it was made to compete with Monopoly, but rigged so yo don’t endlessly accumulate, working to humiliate your playmates. It’s both strategic and based on luck. We can play for hours and last summer we lost many summer nights to it. If you like Star Trek and you like games, you should do yourself a favor and get Star Trek Catan. It’s fun to build starships and space docks, collect dilithium, and beat your kids.

Conclusion

Could I go on? Of course, but I wont. Do you know how many of my birthdays and Father’s Days have passed just this year? :-) Every one of them introduces a little bit more Star Trek into this house. And when the girls have a birthday, I make sure to tuck something Trek in their stocking, too. (so to speak) And, now, in three days, CBS is giving me a present, and it only costs me $10 a month, for the rest of the year. Could I torrent the episodes? Of course, but I wont. Could I wait and binge the episodes? Of course, but I wont. I love weekly shows. And, I really like Star Trek. It’s a cake and frosting sort of thing, and I am ready. I could even watch it in my bathrobe. Of course, but I wont.

Cardinal XAML: a reflection

2017-08-29T16:17:00.001-06:00

In 2014, at the VS Live in Chicago, Ben Dewey, a Microsoft MVP for Windows Client at the time, presented the session: XAML Anti-patterns. Not to be confused with Markus Egger’s excellent series with the same name in Code Magazine (also in 2014); Ben’s session had the playful subtext: The Seven Deadly Sins of XAML Development.

Between the two authors, they saw a regular set of common developer practices that harmed the efficiency and maintainability of XAML applications. In this article, I wanted to iterate those insights, consider the actuality of them, and review if they remain relevant to modern developers using newer, evolved XAML technologies and tooling.

Okay. Before I start, it’s only fair to confess I also, in 2014, took the Biblical approach to software, presenting The Ten Commandments of MVVM at Dev Intersections, writing a never-published blog of the same title.

Let’s begin with my 10 commandments, evaluate their value today, then do the same for the other authors so long ago.

1. Software delivery is job one

Still valid? yes, and it always will be

You might be surprised to sit at a table of architects hearing them argue: “bad code makes software useless”. I think the argument goes: with architectural debt, a code base cannot be maintained or enhanced. Though true, this axiom is teaching the goal of software is the product, not architecture. The test of a good developer/architect is their balancing those competing factors.

2. Reconsider MVVM altogether

Still valid? yes

Every design pattern has a certain cost. Sometimes the cost is in size: constraining resources to the app’s physical or memory footprint. Sometimes it is in performance: requiring more code for the sake of the developer’s convenience. These aren’t always wrong, but this axiom is teaching that design patterns, even MVVM, should be added with mindfulness, not blindness.

3. Choose MVVM for your own reasons

Still valid? yes

One common reason to choose MVVM is unit-testability. But, if we were to be honest, many development teams aren’t motivated to employ unit tests – for whatever reason. If the value of MVVM is for unit testing, then those development teams might also misperceive the value of MVVM. This axiom is teaching that patterns solve different problems for different apps; we aren’t all the same. MVVM solves unit testing for you, but something else for me.

4. Don’t build the model for the UI

Still valid? yes

This is specifically referring to the model in your service layer. Many developers surface their service models in their UI, and when a UI-specific property is required, they add it to their service layer model. I’ve done it, but have learned. This axiom is teaching that models in your service layer are for your service layer and your UI layer needs its own models – reuse feels like we’re working smarter but we’re really working so much harder.

5. Reference only in one direction

Still valid? yes

This is referring to your view-model, that it should not reference your view. It continues that your model would not reference your view-model, though your view-model references your model. This ideal not only keeps things clean, it also prevents hard-coupling that makes new, future features difficult and expensive to add. This axiom is teaching that in MVVM, the view sees the view-model, and the view-model sees the model - not the opposite.

6. Have only one view for one view-model

Still valid? yes

Some views are nested in other views and have their own reusable view-models. Every view has a view-model, but what do you do when two views are nearly identical? Should they share a view-model. The argument against shared view-models follows the reasoning that views today might change tomorrow, and a single view-model fakes a kind of polymorphism to support it. This axiom is teaching to go ahead, bite the bullet, and create those near-identical view-models for the sake of clarity now and an unforeseen future.

7. Use binding

Still valid? yes

It’s difficult to imagine a XAML developer not using binding. Without MVVM, it is less relevant, but you can still use it against the code-behind file. Binding and commanding allows you to declare your UI in the XAML designer, minimizing the need for raw, custom code – which will need to be tested manually. This axiom is teaching binding, like several framework features, should be your default approach, not custom-building one.

I would like to follow-up that binding is notoriously costly when it comes to performance, especially in WPF. But in UWP, compiled binding “{x:Bind}” was introduced to solve the performance issue. With RS3, or the Creators Fall Update, of Windows 10, compiled binding is basically in feature-parity with classic binding “{Binding}” and should be your default, when possible.

I would also like to follow-up that Commanding, which is an artifact of the binding pattern, allows developers to bind to the Click event of a Button, while maintaining two-way control over the Enabled property of the same Button. With compiled binding, developers can now bind events directly to a method in their view-model fundamentally calling into question the overhead of ICommand. In fact, you’d work hard to convince me to use it (in UWP).

8. User Experience trumps Developer Experience

Still valid? yes

Well, this one is a painful one. There is an inverse relationship between the user experience and the developer experience. As we discussed above, many patterns introduce some type of cost – a cost almost universally paid by the user. Some patterns slow the app, some complicate the interface, some increase hardware demand. None of these are developer inconveniences. This axiom is teaching that when you weigh the cost/value of any experience, the user experience is, by default, the most important experience in the equation.

I want to follow-up here with a snippet from another talk I give: The Most Important Goals of Software – things like performance, security, user experience, and scalability. Spoiler alert, the most important is User Acceptance. Here’s the reality: if your users hate your app, your incredible architecture, perf., or devops-process won’t change their minds. You’ve failed.

9. Discriminate against code-behind

Still valid? yes

Oh, the frustration when talking to a die-hard MVVM developer. It’s a jihad against code-behind, shaming apps with it, banishing developers who do it. Of course, I exaggerate, but many developers lead with the false premise that MVVM is against code-behind. It isn’t. This axiom is teaching that code-behind can have its place, can solve real problems, but should not be preferred. That is to say, code-behind is wrong, except when it isn’t.

10. There are no commandments

Still valid? yes

Sort of like fanatics of agile methodologies, getting too dogmatic over a design pattern like MVVM doesn’t teach fundamental computer science principles to developers: it frustrates them. Still, MVVM more than most others, is one of the most flexible and fluid design patterns: your implementation and mine may vary vastly, but we are both using MVVM in our XAML apps. Remember, other than having a view-model manage your data, there’s no other fundamental requirement of the MVVM pattern. This axiom is simply teaching: chill out.

This brings us to the end of reviewing my Ten Commandments of MVVM. For the most part, I think we could agree these are still quite relevant, three years later. Most of them, I might add, will remain valid for a long time.

Ben’s deadly sins

Well, here we go, on to Ben Dewey’s deadly sins for XAML developers. These, you will find, are less about the architectural approach to the app, and more the real-world, practical approach by the developer in markup. They are very prescriptive and, as a result, very opinionated. Let’s dig in.

1. Thou shalt not use inline styling

Still valid? was it ever?

If you have code like this: <TextBox FontSize="16" /> then he is recommending that you instead create either <TextBox FontSize="{StaticResource FontSize}" /> or <TextBox Style="{StaticResource Size16TextBox}" />. All three approaches are semantically similar, producing the same result, but are not identical in their execution. I think it’s important to remember execution because it impacts the user’s experience the most directly.

The introduction of a static resource requires the framework to parse and build out that resource before it can assign it to any control’s property. For the sake of reuse, this can be quite valuable to a developer, but let’s not understate that with hundreds or several hundreds of varying controls with similar static styles, the cost to startup is consequential. Is it right to use styles and static resources? Of course. Yes. Should it be a certainty? No.

Aside: I am quite willing to acknowledge care can be taken to reduce the cost and impact of styles and static resources. But, as a general rule, those performance techniques are black magic to the everyday XAML developer, and will not be implemented. It’s because of the latter I think this can’t be a general rule of thumb worth keeping.

2. Thou shalt not use hardcode colors

Still valid? yes

First of all, I could come up with several scenarios where an in-line, hard-coded color makes perfect sense. But generally speaking, the use of color is an intentional part of the user experience. Because user experiences can change based on Light, Dark, and High Contrast and impact theme resources injected at an application’s highest scope, those colors must not be static. Granted, Ben didn’t sell this rule based on the Themes we introduced to UWP a year after, he sold it based on reuse – a sort repeat of number one. But, that doesn’t matter: Theme resources make rule 2 more valid today than ever.

3. Thou shalt not use bitmap icons

Still valid? amen

Wow, this was a big problem in 2014 and it’s a bigger problem in 2017. Using bitmap images in your app for any reason introduces an amazing amount of complexity to handle them properly. Depending on the resolution and capability of your monitor, the built-in resource system in the Universal Windows Platform will self-select assets to render on the screen, meaning if you provide the right asset your app will look great and if you don’t it will blow chunks.

The solution for bitmaps in UWP is far more elegant than UWP, but even that is a near-nightmare. You provide and decorate a bitmap in various scales, letting the PRI subsystem pick the best option. Windows Store can break scaled groups into separate, downloadable asset packs reducing your installation footprint or initial download size, but you need to know what you are doing.

There’s just something painful about the near-exponential feel of including the 100% scale, the 150% scale, the 200% scale, the 250% scale, and the 300% scale of every bitmap in your app over and over. I know, sometimes bitmaps are your only option, but in general, they suck donkey.

Then, using bitmaps in your app can also be dangerous as you gobble up available memory because you improperly decode your images. With RS2, the platform introduced the ability to decode images properly by setting the source of your <Image/> tag to a BitmapImage with a DecodePixelType property.

MSDN: DecodePixelType can be set to Logical or Physical. The default value is Physical. If DecodePixelType is not set, or set to Physical, the image is decoded using DecodePixelWidth and DecodePixelHeight values that represent physical pixels, and the decode operation uses these values directly. If DecodePixelType is set to Logical, the image is decoded using DecodePixelWidth and DecodePixelHeight values that represent logical pixels. Internal logic converts the decode width and height based on device resolution info and how logical and physical pixels are factored on the target device.

Whew.

The better approach today is to use PNG or vector XAML paths, but shortly the platform will introduce the capability to natively render SVG (even animated SVG) and eventually colored fonts which can scale endlessly without the need for extra assets, both inside your app and its tile/live tile.

4. Thou shalt not set properties manually

Still valid? no

The main idea is to not set properties from code-behind. If you read back a few pages, you’ll see my diatribe on code-behind – you can interpolate some of my conclusion from those statements, but setting properties from code-behind is generally wrong. It typically means you are doing things without a view model or, even worse, without using the Visual State Manager. This behavior short circuits the designers ability to help you, check you or preview for you. It also means you can’t use the additional tooling to manipulate the logical tree without potentially breaking your invisible code-behind.

Aside: this rule is effectively an argument for MVVM and view-models. As I stated above I love MVVM, but I also disagree that it is a requirement for an excellent XAML application. I will likely always use MVVM in my apps, but I can understand a mindful developer choosing not to, too.

So, should you set property values of your XAML controls from your code-behind? Well, generally, no. But, a developer doesn’t have to introduce view-models, and with the introduction of Composition UI and its incredible, mesmerizing capabilities, many of which are only through code-behind, you can’t say “don’t do it” without a dozen attached caveats, which effectively invalidates the whole notion of a reusable axiom for XAML.

5. Thou shalt not duplicate chunks of XAML

Still valid? mostly

I would like to dispel a common developer statement: “Don’t repeat code.” This is best characterized as well-meaning stupidity. In a very narrow context, it makes plenty of sense. The more code you write the more code you need to test. Fine. But as a general rule, it coerces developers to introduce abstraction and encapsulation into the nooks and crannies of code, ad nauseam.

Consider, here, the needless complexity of Class01 over Class02:

Don’t get me wrong: if you are paid by the hour, then I understand your desire and attraction to Class02, but generally, there’s nothing wrong with letting a developer write code; they are equally testable. And, should we look at real-world examples, we will find applications with so much freaking code abstraction that reasoning over their logic is nearly impossible, and the duplicity saved is measurably trivial.

But, I digress.

This XAML rule is based on the precept of not repeating code, which, at its heart is reasonable, just generally inapplicable. That being said, XAML markup is a voluminous syntax that, unless it is precompiled (another condition short-circuiting this axiom), must be read, parsed, loaded and rendered. This processing pipeline is relatively expensive and can be reduced by reusing XAML in user controls, just as this rule prescribes. To that end, this rule is dead on and I follow it myself. But there are too many caveats and asides. This is not a rule, just a good habit for developers to adopt as they code.

Aside: part of the origin of this rule is a XAML developer’s natural addiction to binding. Because binding decouples logic, binding should be used as infrequently as possible. Yeah, you read that right. Use data binding for connecting your UI to your view-model and models, sure. But don’t go crazy with element binding because it ultimately frustrates real-world debugging of complex UI in significant applications.

6. Thou shalt not wrap content repeatedly

Still valid? no

One of the best qualities of XAML is its ability to re-template any control or container for to meet immediate needs of the UI. Not to be confused with data templates, these are control templates. Now to it: control templates are both XAML’s best feature and XAML’s worst feature. Why? I am glad you asked.

Have you ever wondered why the out-of-the-box toolbox in Visual Studio is not filled with even more controls than it already has? I mean, really, is it that hard to create a data grid? Well, it turns out, yes. That is to say, when a company like Microsoft makes a control they make it look great, they make it adaptive, they make it low memory, high performance, completely accessible, localizable, and more. Those requirements for first-party controls make their cost high and their construction slow.

I say all that to say this, when you re-template a control, there’s a 99% likelihood that you are going to mess it up – either the style, accessibility, localization, or the future update of the control’s template when the platform is revved a version or two. Again, we aren’t talking about data templates. It is for this likelihood that this rule that ultimately gravitates developers to the creation of custom controls is inherently problematic. We inevitably forestall the native capabilities of controls when we re-template them.

A contrary rule would serve the general XAML community better. Something more like: use the built-in controls and try not to re-template them. They are faster than custom controls. They are more compliant than custom controls. They are, generally speaking, better than custom controls.

Aside: having said all that, if Microsoft can write a good control so can your development team. But, we can all agree ahead of time, such an endeavor is no small task to be “knocked out” in a sprint or two. And, inevitably it will require maintenance as the platform matures.

7. Thou shalt not use absolute positioning

Still valid? yes

Absolute positioning, in XAML, might be best understood as positioning a UI element from 0,0 (or the top-left corner of the viewport). Relative positioning, by contrast moves something closer to or farther from an existing object in an arbitrary location. The RelativePanel, introduced to UWP in Anniversary Update, is a wonderful panel for arranging elements relatively to the panel or siblings within it. Android developers might compare it to RelativeLayout.

The only times you usually see absolute positioning in XAML is when developers use Canvas (which actually requires absolute positioning) and when a UI element is relocated around the interface by changing its margin.

We’ve all done it, there’s no reason to pretend I am better than you – especially here. The Visual Studio XAML designer actually does this by default and is sort of to blame for programming bad developer behavior. Once you also set the right and bottom margins, there’s no wonder new developers wrongly conclude that XAML is difficult and unpredictable. It’s a hot mess.

With the introduction of Windows 10 across various device types including Mobile, IoT, and HoloLens, the adaptive story of UWP apps was pushed to the foreground with force. Developers had to handle the changes of physical dimensions in ways WPF developers generally didn’t. The use of Visual States with the introduction of Adaptive Triggers for Visual States made the arduous task less brutal, but clarified the near-nemesis status of absolute positioning.

There are fewer and fewer games written in XAML. Frameworks like Unity have made it too simple to make compelling games cross-platform while enjoying C# and the Windows development environment. As a result, games, which were the primary use case for absolute positioning, rarely justify the practice; the presence of absolute positioning is generally a developer error.

Aside, the web has taught us developers a lot about how to build responsive and adaptive user interfaces. XAML has, built-in, corollaries of most of the conventions used on the web; it might even have more when you consider the scope and power of the Visual State Manager. The approach is basically the same – and the distain for absolute positioning is also in web development.

Reversed

I like that Ben turned the negative into positives, I will sign-off with his positive slide. The rules are the same, and the current validity remains the same, but it’s just nicer to be positive instead of negative. I think.

I wish I could have agreed more. But, I can’t.

But wait, didn’t I say I would also discuss Markus Egger’s XAML Anti-Pattern article(s) from Code Magazine? Yes. Yes, I did. But, today is August 29, 2017 and Hurricane Harvey is screwing up Houston and that appears to include the Code Magazine servers, which are down right now. So, I will have to circle back and do it later. And, I think we all know, that means I will never do it. :)

Best of luck!