DEV Community: Leon Adato

What “Project Hail Mary” Taught Me About Working in Tech (part 1)

Leon Adato — Tue, 10 Nov 2026 03:00:00 +0000

Pre-Launch Checklist

What follows are some observations and ideas that are inspired by “Project Hail Mary”, both the book by Andy Weir and the movie it inspired. If you haven’t read/watched them (and I highly recommend you do!) and you don’t want it spoiled, you should probably stop reading, bookmark this page, and come back later.

Countdown

As someone who has worked in I.T for over 30 years, I long ago got comfortable with the idea that part of my job was to be a “lifelong learner” – someone who routinely picks up new skills and information in order to keep working. Most of the time, that learning happens at the shoulder of a colleague, taking a course, watching a video, or reading a blog.

All of which are deeply technical types of content. There might be a Star Trek reference or two, but otherwise high adventure and thrilling plot twists are in short supply. Which is too bad, because it can all get pretty dry.

Maybe that’s why, over the years, I’ve looked for (and found) lessons for I.T. practitioners in more popular forms of media – everything from SpiderMan to The Lord of the Rings. No, you probably won’t discover command-line options for kubctl in the midst of the battle at Helm’s Deep, but in the midst of the banter between Gimli and Legolas you just might find an idea or two to better leverage what you know about kubernetes.

And so, in that same spirit I am sharing some of the I.T lessons I found in the story of Grace and Rocky and their heroic adventure among the stars.

Launch

Never Give Up

If there is one lesson I think IT practitioners can take away from the story of Dr. Ryland Grace (who I’m referring to as “Grace” from this point forward), Rocky and the planets they’re trying to save, it’s that you should NEVER give up. I know that sounds cliche’d and overly simplistic, but it still holds true: In the face of a dying sun, humanity chose to come together and first gather information about the threat, then bring the best and brightest minds to analyze that threat and create a plan that might save everyone. In doing so, false obstacles were removed (like considering a junior high school science teacher to be part of this planet-saving operation). The only thing that mattered was both willingness and competence.

And that theme continued throughout the story. Despite a series of challenges that would overwhelm many of us, the characters in the story chose to believe there was a solution, and continued acting as if there was one, they just didn’t know it yet.

In tech, I think the same attitude serves us well. Whether it’s code that won’t compile, or a cluster that won’t build, or an application interface that users find confusing, there is always a solution. Sometimes it’s hidden; sometimes we need to bring in another expert with a different point of view; and sometimes we need to ask whether the problem is even real, or if it’s a manifestation of our own fear or insecurity.

To elaborate, I want to share an experience from almost 20 years ago:

I’d gone to a week long technical “boot camp” – a program designed to help teach me the skills I needed to pass a certification test. The week culminated in the actual test, for those who felt they were prepared enough.

I was in the room with one other student. The exam was proctored, with an observer in the room to both help in case the technology had a problem and also to ensure there was no cheating. As the test progressed, the other student became increasingly more agitated – grumbling, slamming the keyboard, pacing the room, etc. The proctor gave him a little latitude but at a certain point reminded him that there were test rules that had to be observed.

As the clock ran down, this other person gave up. He said there was no way he was going to pass, and he didn’t want to see his miserable score. He got up and left the room. The proctor went to the testing station and clicked through the remaining questions to force the test to end.

There were 10 questions left. He missed passing by 3 points. The reality was that he could have just randomly guessed at the answers and probably squeaked by.

I will admit to having felt the exact same way during certification exams: the absolute certainty that I’d missed every single question, that it was mathematically impossible to pass. In those moments, memory of that other student has kept my butt in the seat and my head in the game. And in almost every situation, I passed by a much wider margin than I had thought possible.

To come back to “Project Hail Mary”, there are times when – like Grace – we’re braver, more resourceful, more capable than we give ourselves credit for. Keep going. Never give up.

Have Someone You Need to Be Brave For

Continuing on that idea of bravery: When it becomes obvious that the mission to Tau Ceti will be a one-way trip, Grace tells mission commander Yáo Li-Jie that he could never do what they’re doing, that he doesn’t have that bravery in him. Yáo replies that Grace just needs someone to be brave for.

Much has been made of the moment near the end of the story, when Grace turns his ship around to save Rocky, even though it means he will never make it home. And that was brave, and it was because he’d found someone he needed to be brave for. But to be honest, Grace shows innate courage throughout the story – from telling Rocky he’s OK with dying (even though he’s terrified of it); to repeatedly taking risks in order to collect data, complete a task, and even to face and learn to interact with a completely alien entity.

The lesson for us is this: Working in tech is neither simple nor stable. We are going to be lifelong learners – the tech doesn’t stop changing and therefore neither can we. It demands (or seems to demand) long hours and sudden interruptions. There’s a certain culture of heroic firefighting that permeates the industry, even though many of us have acknowledged how unhealthy it can become.

For many of us, a career in tech can either burn us out or burn us up. Few are the leaders who keep track of our efforts and say, even in the middle of the work day “You know what? you’ve done enough for one day. Pack it up and hit it again tomorrow when you’re fresh.” That boundary has to come from within ourselves.

And for many of us the strength to find, set, and hold that boundary comes from whoever “we’re being brave for” – meaning whatever greater goal or relationship we’re working for.

Eva Stratt is the quintessential tech leader

Eva Stratt is something of an enigma, both in the book and the movie. She weilds a vast amount of power, seemingly without anxiety or ego. She is single-mindedly driven by the mission to identify the threat to the sun, then to find a solution, then to execute that solution. She’s extremely clear-eyed about what is likely to happen once the existential threat is over, or when the inevitable fallout of the current situation becomes too great to ignore. But until then she is willing to do whatever is needed to save as many people as possible.

Why do I think that’s similar to a great IT leader? I’ve long said that, to be a good manager of techical folks, one doesn’t need to be the best technician. Instead, it’s important to:

surround yourself with good people.
tell them the goals of the organization.
ask them for the best way to achieve those goals.
BELIEVE WHAT THEY TELL YOU.
Clear a path for them to do the work.

This is precisely what Eva Stratt does.

IT managers who understand (and do) this are the ones that enable their team (and the larger organization) to achieve spectacular results. Obviously no result is guarenteed, but managers who follow this model succeed far more often than those who do otherwise.

One other thing that Eva does is makes the stakes for both success and failure clear to the team. She doesn’t hide it or sugar coat it. Far from upsetting or distracting the team, doing so provides critical context for their choices. Early in my career I had an experience that demonstrated exactly how important that context could be:

I was working in a manufacturing facility, and one of the Zebra printers (a case of perfect brand naming for a device that created barcode labels) wasn’t working. I took a look and realized it was going to take me a bit of time to figure out the issue. The problem was that it was coming near the end of my shift, and I needed to get home before my kids got off the bus from school. I told the manager in charge of the production line that I could get to it first thing the next day.

“That’s absolutely understandable,” he said, sounding completely sincere. “You’ve got to take care of your family. But before you go I just want to make sure you understand the situation so you’re not blindsided: None of the parts were’re making can ship without that barcode. And that’s the only zebra we’ve got. And each board is about $5,000 of profit for us.”

I looked at the backlog and realized there were close to 100 boards already waiting for labels, and more coming off the line.

I made a couple of phone calls, re-arranged some things, and stayed on the line until the problem was solved.

The point isn’t any heroics on my part. It’s that I would have made a bad choice without realizing it until tempers flared and everyone was caught up in the typical cycle of blame, justifications, and attempts to cover respective backsides.

Eva Stratt does the same thing, over and over throughout the story.

And the final thing that Eva does that makes her such a great role model is that she takes the time to honestly assess and understand the real strengths of her team – beyond what they say (or believe) about themselves. This, of course, lies at the crux of one of the major twists in the story, in that Eva understands how Grace will rise to the occaision even when he himself is certain he doesn’t have it in him.

Our Journey to the Stars Has Only Just Begun

Like science itself, there are many more lessons for IT professionals waiting to be discovered inside “Project Hail Mary”. In the coming posts, I’m going to explore more of them. In the meanwhile, if you have observations or insights of your own, I would love to hear about them in the comments below.

Until then, ad astra, hopefully without the per aspera.

How NOT to Answer the Salary Question

Leon Adato — Mon, 02 Nov 2026 05:00:00 +0000

Before you read a single line more, I will give the usual but still important caveats – this blog is my opinion, based on my experiences. Take it with a big ol’ grain of salt. Then again, you’re welcome to leave your thoughts in the comments below.

OK, with that out of the way, let me set the stage. A friend who I’ve been helping find a new job recently asked me,

“When an employer asks what’s your desired salary, what’s the best approach?”

I could have sworn I’d covered this point before now. I’ve certainly talked at length about job hunting. I came close to today’s topic when I blogged about salary negotiations.

But, for as many times as I’ve discussed this verbally, it’s never made it to the printed page. So here we go:

There will come a point in a job interview where someone is going to ask about the salary.

if you are smart, that person won’t be you.
if it’s a good interview, the other party won’t ask until close to the end of the process
if it’s like 90% of the interviews I’ve ever had, it will be far, FAR too early.

Which is why I’m writing this blog. Because along with not ASKING the question, you should put off answering this question for as long as possible.

Now I recognize that absolutes – especially in the context of job interviews – are a function of privilege. Someone without the societal leverage that gender, age, ancestry confers; as well as those of visibility, connections, certifications/degrees, or accolades within the industry will have less freedom to make demands (or refuse them). So I’m going to work hard in the space below to offer both explanations and options. Explanations for why a particular strategy or choice is better overall; and options for how a person with less privilege might still be able to execute that strategy.

RULE #1: If they haven’t offered you the job, it’s not time to talk about salary.

Talking about salary early in the process is distracting and unhelpful. While there might (MIGHT!) be some validity in the old excuse that “If we aren’t in the same ballpark, we’re wasting each other’s time”, the truth is that a job is far more than a dollar amount. And that goes for BOTH sides of the hiring desk.

For the candidate, salary is important, but probably not more important than other aspects like the location, other benefits, or, I dunno, THE ACTUAL JOB RESPONSIBILITIES.

I mean, for the love of pants, how can you talk about salary if you haven’t found out whether “donate a kidney” is or isn’t one of the job requirements. Because that kind of thing is going to have a significant impact on my negotiations.

Meanwhile, for the employer, salary is important, but probably not more important than knowing whether the candidate can actually do the job, or get along with their manager, or believes in the mission of the company.

That explains WHY (in my (not so humble) opinion) it’s not helpful to talk about salary. But let’s move to HOW one can avoid that questions. Or at least give enough of an answer that the other party is satisfied enough to continue the conversation:

“RESPONSE #1: I’m looking for a salary that’s within the industry-standard range for this type of role.”

This is the answer I’ve had the most success with. It’s the one that is both honest and also leaves room to actually negotiate later.

It also forces the employer into a position that helps you: They certainly won’t say “We won’t pay the industry standard”, and they probably won’t ask you “What is that range?”

However, you need to be prepared. You need to have done the research to understand what the standard salary range is for this role in your area of the world, and you need to have multiple sources confirming that range. Because every once in a while I’ve had a company that gives me a range that is way out of line, and then it’s helpful to be able to say “According to x, y, and z sources, this is the range. Where are you getting your numbers from?”

The value of this strategy is that it pulls you out of a direct confrontation on how much you feel you are worth versus how much they feel they should pay. Instead you are talking about sources of data and what the data show. At the end of the day, the company might dig in their heels and say “Well despite all of that this is still the range we’re paying.” but you’ve established yourself who is reasonable and works from the data at hand.

RESPONSE #2: It’s difficult to give salary requirements when I don’t know anything about the BENEFITS yet.

If asked for details, you can point out that without understanding all the things that affect your bottom line, it’s difficult (or impossible) to provide a number. Specific elements that affect your salary calculation include

insurance coverage
- and the monthly premium deducted from your paycheck
vacation days
bonuses (whether they are company-wide or individual)
stock options and RSUs
The amount and frequency of cost of living increases
The standard amount for yearly raises

The point in all this is that – while the company is focused on the salary – most employees are far more concerned about our take-home pay, which is affected by all the factors I list above (and more).

Example: I worked at one company that offered me a lower starting salary but also covered 100% of my insurance costs. There was no deduction from my paycheck. So even though my salary was lower, my net-pay was significantly higher than other jobs.

RESPONSE #3: It’s difficult to give salary requirements when I don’t know anything about the JOB yet.

This builds on the previous answer, but focuses on the net labor/responsibility rather than the net dollar amount. It also returns to the “industry-standard range for this role” concept.

Senior developer work deserves senior developer pay, irrespective of the job description. Meanwhile, we’re all too familiar with postings that are clearly “3 jobs in a trench coat” (something I explore in my blog about job descriptions).

Beyond the job responsibilities itself, there’s the aspects of everything from team dynamics to management structure to whether this role has existed in the company before or if you will be creating everything from the output to the processes and procedures yourself.

The point you are making with this response is that you can’t put a number of a job until you know what the job is – how much risk and effort it will entail. That’s as true for IT practitioners as it is for plumbers, doctors, or car mechanics.

This is also a helpful response if the company asks for your salary history. You need to stress that past salaries aren’t relevant because the tasks, level of responsibility, etc. could be completely different.

RESPONSE #4: Let’s focus on the job, because you might not even want me for the role!

If you’ feel comfortable, you can add “…and I don’t know enough about the job to know if it’s something I’m interested in either.”

The goal here is to re-direct the conversation to the topics that are important to get out of the way BEFORE a salary is the relevant point.

Otherwise time is being wasted discussing a theoretical number before both sides agree that there’s a fit for the work.

RULE #2: The one who gives a number first loses.

Despite this fact, HR reps, recruiters, and headhunters will all try to get you to give a number. They might even try to reassure by saying, “We just want to level set. Nothing is set in stone.”

Let me be clear: As sure as there will be another Sharknado movie, they will ABSOLUTELY throw that number back in your face if you change it.

I’d suggest you continue to return to the “salary range” strategy, because if you give a number, they are going to hold you to that number. If they continue to press, you can put it back on them by asking “What salary did you have in mind?”

Most times the recruiter gets the point and moves on.

RULE #3: It’s not privilege, it’s self-preservation

As I mentioned at the start, I recognize that some of my experiences come from a place of privilege. I’m a cis-gender, heterosexual, middle aged white dude with 37 years experience in the tech industry. I basically have all the privilege a human body can hold.

That said, I’d like to propose that what I’m suggesting in this blog is more than just a function of that privilege. It’s also based on my experiences with having NOT given these answers.

When I failed to stand up for myself, I ended up not only making less money, I found myself in jobs I didn’t want, working for organizations who took advantage of me, and in situations where I ultimately had to get out and ended up in a worse spot than when I’d started.

I recognize that everyone’s experiences and life pressures are different. Never the less, I’d like to share some of my observations here. Take them for what they’re worth to you.

If the salary is a sticking point, it’s a red flag. It indicates that your cost to them is the single most important element of your employment. That is not likely to change once you start the job. They will continually look for ways to increase your output while reducing your compensation.

If they are so miopically focused on salary that they would pass on a candidate with the skills and experience to do the job, then that’s a huge tell on their part.

Many of the recruiters I’ve spoken to who can’t get past the salary have been hiding the fact that there isn’t really a job in the first place. Or that YOU are the product – meaning they are collecting a database of people to sell to other organizations, rather than having a database of jobs and working to match people to them.

A variation of this is when they don’t know what they want, so they interview a whole mess of different people hoping “they’ll know it when they see it.” The problem is that the “it” they are looking for is “the right price”, not the “the right candidate.”

Some recruiters are able to move forward in the conversation, but they choose not to because this is a power trip for them.

In all of the above scenarios, the likelihood of succeeding in that role, for that company, is low.

RULE #4: Take Care of Yourself

If you’re in a position where you can’t be picky, don’t be picky. Take the job. But my advice in that case is to keep looking, because this has a high likelihood of being a bad fit.

In addition, start thinking now about how you’ll explain this in the future. Let’s say you take the job, and keep looking. What are you going to say to the next interviewer when they ask why you’re looking to leave? I’ve already written about how this, more than any other question, could lose you the job. Be prepared.

RULE #5: If It’s Not Going to Work, Have Fun

Let’s say you’re in a lose-lose situation. They aren’t going to move past the salary conversation, and you know with absolute certainty that you aren’t going to take the job.

In that moment, recognize that you truly have nothing to lose. Use this moment for research. What happens if you fully stand up for yourself? What happens if you push back?

In that case, I’d like to provide one of my favorite snarky responses, straight from my friend Corey Quinn.

RESPONSE #5: I’m looking for $80 million and a company helicopter.

In Summary:

The correct answer my friend’s original question

“When an employer asks what’s your desired salary, what’s the best approach?”

is (IM(ns)HO)

“By saying as little as you can possibly manage early in the conversation; pushing the discussion of money until after you’ve demonstrated your potential value to the company. If you have to answer, give a range not a number, and back that range up with sources. Once a job offer is made (or imminent), the company should be the one to make the first move. All of this is done with the over-arching guideline of doing so without ruining your prospects of getting the job.”

EDITS:

Deepest thanks to everyone (including the entire HackerNews crew!) for much insightful feedback. In the space below I’m going to keep a log of edits based on feedback. And I plan a follow-up to this blog as well.

2/17/26 – changed summary from:

The correct answer to the question

“When an employer asks what’s your desired salary, what’s the best approach?”

is

“As little as you can possibly manage, without ruining your prospects of getting the job.”

Zmanim-WP: Shabbat

Leon Adato — Mon, 26 Oct 2026 04:00:00 +0000

If you’ve been following this blog, you’ll know that I’ve been working on my Zmanim-WP plugin for WordPress for a while now. This blog series is designed to help you dig deeper into the plugin and understand what it does, how it works, and whether it’s right for your needs.

In the first 5 parts of this series, I more or less worked through the parts of the day, from early morning until late night.

In this section I’m going to focus on one of the most obvious use-cases for my Zmanim-WP WordPress plugin: Shabbat. Specifically, we’re going to look at the shortcodes for:

Candle lighting ([zman_candles]) – This will display the time for lighting candles on Friday eventing.
The Parsha ([zman_parsha]) – Displays the name of the Torah portion read that week.
Yom Tov and Special Shabbatot ([zman_yomtov]) – If Shabbat falls on or during a holiday, this will display the name of the holiday. Additionally, if it’s a Shabbat with a special name (Shabbat Zachor, Shabbat Shekalim, etc), that will be displayed.

As with the other shortcodes in this series, these can be used as-is, or with the options described in the first post of the series.

Examples:

[zman_candles date="saturday"]
[zman_candles date="saturday" dateformat="g:i:s a"]

In addition both [zman_parsha] and [zman_yomtov] will take the lang= option, so that the output can display in English or Hebrew.

It’s a Matter of Opinion… kind of

None of the shortcodes require you to choose a Rabbinic opinion (shita) per say. But Candle lighting does allow you to insert your personal (or organizational) opinion of sorts. While it’s generally understood that candle lighting is 18 minutes before shkia (sunset) on Friday, some organizations will print a different time for various reasons. Therefore on the Zmanim-WP “Standard Times” page, you have the ability to change that number from the default.

No Rest For the Weary

After covering Shabbat, what else might there be? It turns out, I coded the Zmanim-WP plugin with a few more tricks up it’s sleeve. In the next installment, I’m going to cover “early” Shabbat settings.

See you next time.

Zmanin-WP: Common Codes, part 3

Leon Adato — Mon, 19 Oct 2026 04:00:00 +0000

“Dancing in the Dark”

If part 1 was focused on the zmanim for the start of the day; and part 2 looked afternoon times, it stands to reason that today we’ll check out the shortcodes that help calculate the end of the day.

Start of Bain HaShmashot ([zman_bain]) – The time between sunset (“shkia”, in halachic terms) and night (“tzait hakochavim”) is sort of a halachic no-man’s-land, and therefore a lot of things that can only be done during the day (or at night) are no longer permitted. For this reason you need to know when this time is to avoid accidentally crossing a line.
Tzait HaKochavim ([zman_tzait]) – The time when 3 stars are visible in the sky, signifying the arrival of “night time”
sunset ([zman_sunset]) – Nautical sunset, also called “shkia”.

The above three are still “regular” zmanim – things that one might expect to see on a sheet of times. The last two (for this week) are “special” zmanim that I’ve included in the plugin because they are so darn useful:

earlyshkia ([zman_earlyshkia]) – The earliest shkia for that week (see more on this below).
lateshkia ([zman_lateshkia]) – The latest shkia for that week (see more on this below).

I’ll elaborate on these more in their own specific section.

Same as the other posts, these shortcodes can be used as-is, or with the options described in the first post of the series.

Examples:

[zman_bain date="saturday"]
[zman_tzait date="saturday" dateformat="g:i:s a"]
[zman_sunset offset=-20]
[zman_earlyshkia dateformat="g:i a"]

A Matter of Opinion

Bain HaShmashot and Tzait haKochavim require you to select a shita – a Rabbinic opinion – for it’s calculation. I plan to elaborate on each of these items in another series, but some details can be found on the KosherJava documentation site: https://kosherjava.com/zmanim/docs/api/com/kosherjava/zmanim/ComplexZmanimCalendar.html#getBainHashmashosRT13Point24Degrees()

Start of Bain HaShmashot ([zman_bain]) – “bainHashmashosRT13Point24Degrees”, “bainHashmashosRT58Point5Minutes”, “bainHashmashosRT13Point5MinutesBefore7Point083Degrees”, “bainHashmashosRT2Stars”, “bainHashmashosYereim18Minutes”, “bainHashmashosYereim3Point05Degrees”, “bainHashmashosYereim16Point875Minutes”, “bainHashmashosYereim2Point8Degrees”, “bainHashmashosYereim13Point5Minutes”, “bainHashmashosYereim2Point1Degrees”
Tzait HaKochavim ([zman_tzait]) – “tzais72”, “tzaisGeonim3Point7Degrees”, “tzaisGeonim3Point8Degrees”, “tzaisGeonim5Point95Degrees”, “tzaisGeonim3Point65Degrees”, “tzaisGeonim3Point676Degrees”, “tzaisGeonim4Point61Degrees”, “tzaisGeonim4Point37Degrees”, “tzaisGeonim5Point88Degrees”, “tzaisGeonim4Point8Degrees”, “tzaisGeonim6Point45Degrees”, “tzaisGeonim7Point083Degrees”, “tzaisGeonim7Point67Degrees”, “tzaisGeonim8Point5Degrees”, “tzaisGeonim9Point3Degrees”, “tzaisGeonim9Point75Degrees”, “tzais60”, “tzaisAteretTorah”, “tzais72Zmanis”, “tzais90Zmanis”, “tzais96Zmanis”, “tzais90”, “tzais120”, “tzais120Zmanis”, “tzais16Point1Degrees”, “tzais26Degrees”, “tzais18Degrees”, “tzais19Point8Degrees”, “tzais96”, “tzaisBaalHatanya”, “tzais50”

Meanwhile, Sunset ([zman_sunset]), earlyshkia ([zman_earlyshkia]), and lateshkia ([zman_lateshkia]) don’t require any additional considerations.

Early and Late?

It’s not uncommon to want to set a time – for afternoon prayers, as an example – to be x minutes before sunset. The problem is that this time moves throughout the week – as much as a minute or even 2 per day!

To make things more complicated, part of the year the earliest time will be on (or closer to Sunday; at a different time of the year it will be on (or closer to) Thursday.

Shuls end up in a situation where they either have different times through the week (which is both confusing to the congregation and leads to many showing up late), OR they hedge their bets and set a time that’s leisurely at the start of the week but becomes faster and faster as the time for sunset gets shorter.

To alleviate this, I created two shortcodes.

earlyshkia ([zman_earlyshkia]) will look at all the sunset times from Sunday through Thursday, and return the earliest one.
lateshkia ([zman_lateshkia]) will, as the name implies, look at all the sunset times from Sunday through Thursday and return the latest one.

Depending on your synagogue’s needs, you might need one or the other. And it’s important to note that both shortcodes also use the offset= option. This allows you to set a service time that’s a set number of minutes before (or after) the earliest (or latest) sunset of the week.

As I said in the last post, I know that this can feel like a lot. Use the codes that make sense, with the options that you need. If you have questions, you know where to find me.

Until next time!

Zmanin-WP: Common Codes, part 2

Leon Adato — Mon, 12 Oct 2026 14:00:00 +0000

“Sunny Afternoon” – The Kinks

The last post covered the zmanim for the morning hours so, logically, this one is going to focus on halachic times for the afternoon. As a reminder, the focus of this series of blogs is HOW to use each shortcode. I’m open to digging into the WHAT (and even the WHY) if you want. Let me know in the comments. For today, we’ll be looking at:

Chatzot ([zman_chatzot]) – Solar noon, the point halfway through the available sunlight for that day.
Mincha Gedolah ([zman_gedola]) – The earliest time to pray Mincha (afternoon) prayers. This comes a half hour after mid-day (chatzot). But of course, “a half hour” is somewhat complicated.
Mincha Ketana ([zman_ketana]) – Some hold it’s better to wait further into the day for afternoon prayers. Mincha ketana happens at the last 2 1/2 hours before sunset.
Plag haMincha ([zman_plag]) – This time occurs halfway between Mincha Ketana and sunset and is yet another time some hold as preferable for afternoon prayers.

As with the shortcodes in part 1, they can be used as-is, or with the options I described in the first post of the series.

Examples:

[zman_chatzot date="saturday"]
[zman_gedola date="saturday" dateformat="g:i:s a"]
[zman_ketana offset=-20]
[zman_plag dateformat="g:i a"]

A Matter of Opinion

Each of these shortcodes requires you to select a shita – a rabbinic opinion – for its calculation. I plan to elaborate on each of these items in another series, but some details can be found on the KosherJava documentation site: https://kosherjava.com/zmanim/docs/api/com/kosherjava/zmanim/ComplexZmanimCalendar.html#getAlos60()

Here are the shitot for the shortcodes we’re looking at in this post:

Chatzot
- chatzosAsHalfDay
- fixedLocalChatzos
Mincha Gedolah
- minchaGedola
- minchaGedola30Minutes
- minchaGedola72Minutes
- minchaGedola16Point1Degrees
- minchaGedolaAhavatShalom
- minchaGedolaGreaterThan30
- minchaGedolaAteretTorah
- minchaGedolaBaalHatanya
- minchaGedolaBaalHatanyaGreaterThan30
- minchaGedolaGRAFixedLocalChatzos30Minutes
Mincha Ketana
- minchaKetana
- minchaKetana16Point1Degrees
- minchaKetanaAhavatShalom
- minchaKetana72Minutes
- minchaKetanaAteretTorah
- minchaKetanaBaalHatanya
- minchaKetanaGRAFixedLocalChatzosToSunset
- samuchLeMinchaKetanaGRA
- samuchLeMinchaKetana16Point1Degrees
- samuchLeMinchaKetana72Minutes
Plag haMincha
- plagHamincha
- plagHamincha120MinutesZmanis
- plagHamincha120Minutes
- plagHamincha60Minutes
- plagHamincha72Minutes
- plagHamincha90Minutes
- plagHamincha96Minutes
- plagHamincha96MinutesZmanis
- plagHamincha90MinutesZmanis
- plagHamincha72MinutesZmanis
- plagHamincha16Point1Degrees
- plagHamincha19Point8Degrees
- plagHamincha26Degrees
- plagHamincha18Degrees
- plagAlosToSunset
- plagAlos16Point1ToTzaisGeonim7Point083Degrees
- plagAhavatShalom
- plagHaminchaAteretTorah
- plagHaminchaBaalHatanya
- plagHaminchaGRAFixedLocalChatzosToSunset

I know that this can feel like a lot. A good rule to go by is that, if you don’t have a reason to choose otherwise, selecting the default won’t get you into too much trouble.

Until next time!

Zmanin-WP: Common Codes, part 1

Leon Adato — Mon, 05 Oct 2026 14:00:00 +0000

“…And There Was Morning…”

There are a four shortcodes that help calculate times related to the start of the day.

Sunrise
Alot hashachar
Sof Zman Kria Shema
Sof Zman Tefilah

I’ve discussed some of these times in other parts of this series and I want to keep the focus of these blogs on HOW to use each shortcode. Feel free to let me know in the comments if you want a more explicit tutorial on each of these (and upcoming) times and when they are used.

Sunrise ([zman_sunrise])- this is, as the name implies, the time the sun rises. I covered the shortcode extensively in the previous blog post.
Alot hashachar ([zman_alot]) – before “sunrise” (when the disk of the sun appears over the horizon) is “dawn”. This is a somewhat murky concept, but it basically relates to the time the first light of the sun can be seen coming over the horizon.
Sof Zman Kria Shema ([zman_shema]) – the latest time one can say the Shema prayer.
Sof Zman Tefilah ([[zman_tefilah]]) – the latest time one can say morning (shacharit) prayers.

To these I’m going to add one more: The date itself ([zman_zmandate]).

Each of those shortcodes can be used as-is, or with the options I described in the previous blog post.

Examples:

[zman_sunrise date="saturday"]
[zman_shema date="saturday" dateformat="g:i:s a"]
[zman_alot offset=-20]
[[zman_tefilah dateformat=”g:i a”]]
[zman_zmandate]

But, of course, there’s more.

Special Options

In addition to the standard options, there are special options that only apply to certan shortcodes. Today, I’m going to look at just one:

lang

This let’s you control whether information displays in English (the default) or Hebrew. It works for the following shortcodes:

Rosh Chodesh ([zman_chodesh])
the Molad ([zman_molad])
the Parsha ([zman_parsha]).
Shabbat Mevorchim ([zman_mevorchim])
the date ([zman_zmandate])

For the date ([zman_zmandate]) you can also specify “transliterated” (or “translit” or even “trans”) to give an English-ified version of the Hebrew date.

So, while [[zman_date lang="hebrew"]] would give you:

י״ד טבת תשפ״ו

[[zman_date lang="transliterated"]] would render as:

14 Tevet, 5786

A Matter of Opinion

Unlike my last blog on the plugin, where I dug into the options, in this case the complexity comes from the initial setup:

Most of the standard time options give you the chance to select the Rabbinic opinion (“shitah”) used for it’s calculations. For example, Alot hashachar could use any one of the following opinions:

alos72
alos60
alos72Zmanis
alos96
alos90Zmanis
alos96Zmanis
alos90
alos120
alos120Zmanis
alos26Degrees
alos18Degrees
alos19Degrees
alos19Point8Degrees
alos16Point1Degrees
alosBaalHatanya

What each of these items mean, and what circumstances they should be used in, is the topic for another day (and probably another 5 blog posts). Until then, you can get some details on the KosherJava documentation site: https://kosherjava.com/zmanim/docs/api/com/kosherjava/zmanim/ComplexZmanimCalendar.html#getAlos60()

Here are the shitot for each of the shortcodes we’re covering today:

Alot hashachar ([zman_alot])
- alos72
- alos60
- alos72Zmanis
- alos96
- alos90Zmanis
- alos96Zmanis
- alos90
- alos120
- alos120Zmanis
- alos26Degrees
- alos18Degrees
- alos19Degrees
- alos19Point8Degrees
- alos16Point1Degrees
- alosBaalHatanya
Sof Zman Kria Shema ([zman_shema]) “sofZmanShmaMGA
- sofZmanShmaGra
- sofZmanShmaMGA19Point8Degrees
- sofZmanShmaMGA16Point1Degrees
- sofZmanShmaMGA18Degrees
- sofZmanShmaMGA72Minutes
- sofZmanShmaMGA72MinutesZmanis
- sofZmanShmaMGA90Minutes
- sofZmanShmaMGA90MinutesZmanis
- sofZmanShmaMGA96Minutes
- sofZmanShmaMGA96MinutesZmanis
- sofZmanShma3HoursBeforeChatzos
- sofZmanShmaMGA120Minutes
- sofZmanShmaAlos16Point1ToSunset
- sofZmanShmaAlos16Point1ToTzaisGeonim7Point083Degrees
- sofZmanShmaKolEliyahu
- sofZmanShmaAteretTorah
- sofZmanShmaFixedLocal
- sofZmanShmaBaalHatanya
- sofZmanShmaMGA18DegreesToFixedLocalChatzos
- sofZmanShmaMGA16Point1DegreesToFixedLocalChatzos
- sofZmanShmaMGA90MinutesToFixedLocalChatzos
- sofZmanShmaMGA72MinutesToFixedLocalChatzos
- sofZmanShmaGRASunriseToFixedLocalChatzos
Sof Zman Tefilah ([[zman_tefilah]])
- sofZmanTfilaMGA
- sofZmanTfilaGra
- sofZmanTfilaMGA19Point8Degrees
- sofZmanTfilaMGA16Point1Degrees
- sofZmanTfilaMGA18Degrees
- sofZmanTfilaMGA72Minutes
- sofZmanTfilaMGA72MinutesZmanis
- sofZmanTfilaMGA90Minutes
- sofZmanTfilaMGA90MinutesZmanis
- sofZmanTfilaMGA96Minutes
- sofZmanTfilaMGA96MinutesZmanis
- sofZmanTfilaMGA120Minutes
- sofZmanTfila2HoursBeforeChatzos
- sofZmanTfilahAteretTorah
- sofZmanTfilaFixedLocal
- sofZmanTfilaBaalHatanya
- sofZmanTfilaGRASunriseToFixedLocalChatzos

My goal here is not to overwhelm you. Rather, I want to emphasize that, for each of the different shortcodes, you should look over, consider, and select the opinion that best fits your needs.

Until next time!

Zmanim-WP: Getting Started

Leon Adato — Mon, 28 Sep 2026 14:00:00 +0000

If you’ve been following this blog, you’ll know that I’ve been working on my Zmanim-WP plugin for WordPress for a while now.

If you haven’t, you can check out everything written so far using this link.

And, while the docs will give you a high level overview, I realized that some folks might want a more detailed set of instructions. That’s what this blog series is going to be about – showing off each aspect or feature of the plugin with details on how to use it.

In this blog, we’ll just take a look at a couple of the features that are both simple and, at the same time, also allow you to explore a lot of options that are common across the plugin.

Sunrise, Sunset

More than a catchy lyric from a popular 1963 Broadway musical, sunrise and sunset form the basis of almost every other time calculation. So it makes sense to start with those two commands. The most basic usage is the shortcode itself:

‘[zman_sunrise]‘

or

‘[zman_sunset]‘

When added to a page, post, widget, newsletter, (etc), this will display the time of those events on the date it is viewed for the location you indicated on the main options page.

Location, Location, Location

…this will display the time of those events on the date it is viewed for the location you indicated on the main options page.

Let’s break down some of the parts of that sentence:

“on the date it is viewed”

The Zmanim-WP plugin works in realtime. If you put ‘[zman_sunrise]‘ on a WordPress page and look at that page on a Monday, you’ll get sunrise for Monday. If you go back and look at it on Tuesday, you’ll get sunrise for that Tuesday.

At least by default. There are ways to be more specific, and we’ll get to that shortly.

“for the location you indicated on the main options page”

Before the Zmanim-WP plugin will work at all, you have to fill out the fields on the Main Options page. These include your location (the latitude and longitude) as well as the time zone. There are other options on that page, but for any time calculation to work, you need to these items in place.

Shortcode Options

In addition to the shortcode itself, Zmanim-WP supports options that let you change everything from the display language to the date shown and beyond.

The parameters which are available across all (or at least most) Zmanim WP shortcodes are:

date

This lets you set a date other than “whatever date it is when I look at it. Valid options include:

today – This shows the zman for the current date (when the page / post is being viewed). Yes, it’s the default action and you don’t actually NEED to include this. But I added it into the program for the sake of completeness.
tomorrow: This will show the time for the day after the current date.
sunday, monday, tuesday, etc: This will give the time for the next upcoming weekday of that name. So if it’s Tuesday and you used [6:03 am] then you’ll get sunrise for the NEXT Monday, not the one that just passed.
(an actual date): Any reasonable date format (2023-01-20, Jan 20, 2023, 1/20/23, etc.) will show the time for that specific date.

Example: [6:00 am]

Example: [7:47 am]

offset

This lets you get a time plus or minus the number of minutes (including fractions – i.e. 10.5) you specify. This can be useful if, for example, weekday Mincha starts at 20 minutes before sunset each day.

Example: [zman_sunset offset=-10]

Example: [zman_sunset offset=20]

Example: [zman_sunset offset=+20]

dateformat

Sometimes you want the date to show DAY mm/dd (i.e. “Mon 3/15”). Sometimes you want it to show as yyyy-dd-mm (i.e. “2025-03-15”). Or you want the time to show as hh:mm:ss am/pm (i.e. “09:15:22 am”). The “dateformat” option lets you specify what the output should look like, using the standard PHP date/time formatting codes. Use this link to see all your options: https://www.php.net/manual/en/datetime.format.php and this tutorial for more information: https://www.tutorialrepublic.com/php-tutorial/php-date-and-time.php.

Example: [zman_sunrise dateformat="m/d/Y h:i:s a"]

Putting it all together

When used in combination, these options allow a significant level of control.

[zman_sunset date="friday"] – gives sunset for the upcoming Friday
[zman_sunset offset=+45 date="saturday"] This will give the time that is 45 minutes after sunset on the upcoming Saturday
[zman_sunset offset=+72 dateformat="m/d/Y h:i:s a"] this would give the time 72 minutes after sunset, in the format of month/day/year hour:minute:second am/pm.

We’ve only just started getting started

Sunrise and Sunset are only the first two of a long list of shortcodes available in the Zmanim-WP plugin for WordPress. I’m going to continue to explore them in the coming weeks.

If you have questions about the plugin or anything I’ve shared, feel free to reach out in the comments and ask!

…And Sometimes the Bear Gets You

Leon Adato — Mon, 21 Sep 2026 14:00:00 +0000

I got scammed.

This isn’t a story about how “…once upon a time, I got scammed.” It wasn’t a younger, less experienced, more trusting me.

No. The person who got scammed was the “now-me”. The one who was just a few hours younger than the one who’s writing this blog.

True to the title of this post, it was one of those moments where impulse control (not enough) and desire (too much) conspired to blind me to multiple moments that should have been big flashing caution signs.

I’m writing this because sometimes showing your scars is the quickest and easiest way to help others avoid making the same mistake. I’m also writing this because it can (and does) happen to every one. When I filed the police report, the office said “I work in this department, and I’ve gotten scammed.”

So point #1 of this blog is: If it’s happened to you, I hope this gives you comfort knowing you’re not alone.

“Get to the point, Leon. What happened?”

I’m starting a new job (which is a story for another day) and got a stipend for home-office improvements. I’ve wanted a Sony zv-e10 for all the video work I’ve been doing. So last week I started scanning the bargain sites just to see if I could find a deal. One of the sites I checked Craigslist.

Now before I go further, this isn’t a slam on Craigslist at all. It’s a nice site that has a place in the internet ecosystem that I’ve used to both buy and sell in the past. I’m only mentioning it because it’s NOT the same as eBay or Amazon marketplace or some of the other more sophisticated sites. It’s effectively the local newspaper’s “For Sale/Trade” section. And I’m here to tell you it should ONLY be used when you can meet up IRL. Because as soon as you consider shipping the item, the guardrails are gone and fraud quickly enters the picture.

AskMeHowIKnow.

To make a long story short, I found a bargain that was too good to be true; agreed to buy with too little skeptical consideration; and paid too quickly with too few protections. It was only after the money was out of my account and the person on the other side started trying to squeeze me for more cash that I stopped and considered what had happened.

If I’m being brutally honest, it hurt. I broke out in a cold sweat driven by sheer disbelief. In the moment when it dawned on me that I – a person who’s been terminally online since before “online” was even a thing – had been had, my emotions were no more sophisticated or insightful than a rank novice.

“You don’t rise to the occasion, you sink to the level of your training.”

– Archilochus

While I basically live online; and use sites (including Craigslist) to buy and sell; and know that the risk of scams is ever-present; despite all of that, it became clear that I’d never trained or prepared to ACTUALLY be on the receiving end of one.

If you ignore or forget everything else in this blog, please remember this point: If you don’t spend time thinking through how a scam would realistically play out in your situation – if you don’t work through your potential actions, re-actions, and contingencies – then you’ll fall to your most basic reactions. Which are, in most cases (and certainly in my case), neither pretty nor particularly sophisticated.

The thing that I found most insidious and surprising was my own desire make the scam not happen by willfully ignoring that it had happened. I wanted so very much NOT to be the victim of a scam that I let myself continue the conversation long past the point where I should have blocked and moved on. Thankfully I didn’t let that desire drive me to throw good money after bad, but I need to be clear with you that if it wasn’t for a few lucky glitches in the payment system – which slowed me down just enough for reason to overtake shame, I might have let the situation continue in the vain hope that it would somehow turn itself around.

With the goal of informing folks who haven’t been through this, here are a few of the warning signs I could have (and should have) paid closer attention to.

I only communicated with this person via text. Once there was an agreement to buy, I should have called to verify the number was answered by a human. When I finally DID call the number, it went to a completely different state than the area code indicated, and nobody answered.
When I asked the person to call me (very late in this process, after I was all but certain I was being scammed) the scammer insisted the call wasn’t going through.
The scammer sent me screenshots of shipping costs, but I didn’t double-check them from my side. It turns out they were digitally manipulated.
To pay, I was given an email that was clearly a randomized hotmail account: [email protected]
My initial attempt to pay failed, and resulted in my account being locked until I called the provider. That doesn’t happen by accident, I tripped one of their systems that warned of potential fraud. But again, I really wanted that camera, so I willfully ignored it.
To pay for shipping, I was given a different person, with a different email: [email protected] – this payment failed completely. So they gave me another email to try: [email protected].

By this point, I’d gotten over my initial denial and was certain this was a scam. The correct action at this point is to:

Document everything
Contact local law enforcement and file a report.
File a report with ReportFraud.ftc.gov

Filing those reports is going to feel like pouring salt in a wound (at least I know it did for me). It’s also going to feel pointless because the scammers are more than likely NOT within the same jurisdiction. Hell, they’re probably not in the same country. BUT… you never know if there isn’t an active operation in progress, and your information adds data points. So my advice is to breathe through the discomfort and file those reports.

I’m still mad that this happened to me – that I allowed it to happen and actively participated in it – but I also recognize I was lucky to lose relatively little. While it was an expensive lesson, it’s nevertheless a lesson I won’t forget any time soon. And it’s an experience I’m willing to share in order to help others avoid it.

Finally, as I (somewhat ruefully) joked with the officer who took my report, this isn’t the largest amount I’ve spent while doing research for a blog. So if nothing else, I got a good story out of it for a bargain price.

AI CURMUDGEON: AI is a backhoe

Leon Adato — Mon, 14 Sep 2026 14:00:00 +0000

It’s been a couple of years since May 23, 2023, when I posted my first rant about AI in general and ChatGPT (properly pronounced “chat-jippity”) in particular.

In that blog, I compared AI to a calculator:

In the hands of a novice, a scientific calculator is far more likely to be used to spell out “fart” than it is to find the proof to Fermat’s theorem. (Use hex mode, put in “46415254”. How I know this is a story for a different day.) Like the calculator, the spreadsheet, and the internet, AI-driven LLM tools are likely to change HOW we do our work, but not the fact that humans will still be the ones doing the work in the first place.

Today I want to offer another perspective, inspired by a LinkedIn post (you can find it here) by the inimitable Dave Mangot.

He started by referencing someone who experienced the consequences of their poor choices, when it came to “vibe coding” with an AI:

Then Dave followed up with this story:

A long time ago I started at a new job and everyone was logging to the Unix hosts as “root”. I asked a friend of mine if I was just out of the loop and this was an ok thing now. He replied “You know what we call people that do that? Amateurs”.

Dave continued with his own observation:

Despite what all the AI vendors tell you, it’s not there yet and no one really knows when it will be. I’ve spend the last few days coding with an AI Assistant and it’s great! I love it. Never going back.

But it also:

wanted to put the DB password in plaintext in the code

wanted to hardcode the DB config in the code

told me the wrong module name for requirements.txt

I know enough to instruct the Assistant otherwise so it’s fine. >Building a kit car (prototype) you ordered through the post does not mean you are ready to join an F1 team. Maybe someday.

So as I pondered all of this, another analogy occurred to me:

The shovel vs the backhoe

Both a shovel and a backhoe do the same job – they dig holes. The backhoe is certainly faster and more powerful, but in the hands of a novice a shovel can only cause a relatively small amount of trouble, while a backhoe can cause much bigger headaches (both literally and figuratively).

While both could, conceivably dig up a rock, or the sprinkler system, or the main internet feed to your business, the backhoe is much more likely to do so before the operator is aware of what’s happening.

Just to be clear, my point isn’t that automated tools are inherently bad. My point is that, IN THE HANDS OF AN INEXPERIENCED PERSON, an automated tool is much more likely to cause trouble and damage instead of doing good.

This is due to the fact that the automated tool (whether the construction or computing kind) requires experience and expertise to be effective. It’s a labor-saving device only insofar as the operator understands the labor to be done.

In the intervening 2 years since my original AI post, I have heard from many colleagues who’ve used AI tools to great effect. But I’ve seen far more randos who think they can hop up in the cab of the shiny AI-driven excavator and dig a foundation in an afternoon, who only end up causing destruction and confusion.

Software migration: Pain vs Risk

Leon Adato — Mon, 07 Sep 2026 14:00:00 +0000

“And the day came when the risk to remain tight in a bud was more painful than the risk it took to blossom.” – Anais Nin

Over the course of my career, I’ve experienced my fair share of software upgrades, migrations, and replacements. Some have gone smoothly. Many have not. But none of them could be described as “easy”. The reason none were is is because, to paraphrase a famous sword-swinging Spaniard, “…that word doesn’t mean what you (non-IT people) think it means.”

In tech, and especially on the subject of system migrations, “easy” connotes “without significant unexpected issues”. It rarely – possibly NEVER – means “without effort.”

Nevertheless, the suggestion to upgrade (or migrate, or replace) is often thrown around by certain folks (usually business leaders and vendor sales) without a trace of understanding of what that truly entails. As a boots-on-the-ground IT practitioner, hearing it used in this way is nothing short of infuriating.

Upgrades are such a monumental task that teams will go to almost any length to avoid them unless absolutely necessary. “Almost any length?” you ask. A recent LinkedIn post* illustrates just how bad it has to be for a customer to consider migrating:

* I recognize readers might read this particular post and read into it a certain venting of grievances on my part, as a former SolarWinds employee. I want to be clear (and I spell it out below) that this is not the case because MANY vendors are making changes to pricing, causing MANY customer to feel similarly to the original poster. This post is just the most recent one to have crossed my timeline.

SolarWinds, a major player in the technology infrastructure monitoring space, is attempting to force our company into a three-year deal that represents a 543% price increase from our 2023 costs. To put this in perspective. they’re charging 5.6 times the inflation rate. […] I’m now being asked to pay more to monitor our company’s infrastructure than I pay to support that infrastructure itself.

If there is a lesson in this that avoids both showcasing the pain of others (in this case, Mr. DeMersseman) or pointing fingers at any specific vendor (because SolarWinds isn’t the only culprit here by a long shot), it’s that customers – despite the lack of meaningful updates or new capabilities; despite the jacked-up pricing and removal of flexibility; despite almost open hostility from the vendor C-suites – despite all of that and more, STILL haven’t migrated to another tool.

Why? Why would they do that? Because migrating is HARD. In this blog I want to outline just how much risk there is in “blossoming” (as a reference to the quote at the top of this post, by which I mean “migrating to something new”). So much that customers are willing to tolerate this level of pain to remain “tightly within the bud” of the current monitoring solution. I want to outline exactly what you* are asking of your team, when you are being courted by a new software vendor who is promising they can do everything the incumbent solution does (and more, and better) if only you’d switch to their solution. Making matters worse, you* are probably laboring under the belief that “we have too many tools already” (which is, to be honest, probably not entirely wrong.) and so you’ll only consider “…putting a brick in if we can also take a brick (or 2, or 3) out.”

* I’m assuming that YOU, dear reader, are part of the decision makers who buy the software. If you’re not, then I’m writing this to be shared with said decision makers. You’re welcome.

Let’s break down exactly what a software migration looks like – at least in my experience and in my not-so-humble opinion.

First, let’s be clear: I’m talking about the experience of an boots-on-the-ground IT practitioner who has found a tool that does something both important and essential. So much so that they’re willing to attempt the “business justification two-step”.

Imagine being that regular IT pro walking into a room of executives asking questions like the ones Keith Townsend (CTO Advisor) describes in this LinkedIn post. It’s not fun.

Tech people hate (and therefore usually suck at) speaking in terms of the business, so these types of meetings usually devolve into the IT person passionately citing technical stats until the executive shuts them down or caves. For the sake of argument, let’s pretend they cave (spoiler: they never do).

I’ll also remind readers that “I’m adopting a new tool” isn’t seen by most managers as a hall pass to get out of doing your regular job (which is typically 3-jobs-in-a-trench-coat that consumes 50+ hours a week).

The ADDITIONAL work on top of the normal work includes:

Creating the forms for a largely un-necessary RFP.
Working with companies who don’t have a free tier to get a free trial going without making it sound like buying is a sure thing.
Apologizing to the CFO when an over-enthusiastic salesperson skips 2 or 3 levels and calls them directly to see if they can “push” the sale through.
- Yes, that happens. 2 different monitoring solution vendors have done it to me.
Begging for cash and scrounging spare parts to build a lab because nobody will (justifiably) let you test in production.
Setting up the lab yourself. Even the people who would benefit from the new tool usually can’t help because – SURPRISE – they are doing 3-jobs-in-a-trenchcoat too.
Doing the RFP – installing and configuring software for at least 3 companies plus the incumbent and doing detailed comparisons in an attempt to get an apples-to-apples understanding.

But, ok, that’s ANY migration. So let’s wave our magic wand again say we get past the WEEKS (if not months) of effort. AND we’ll wave our wands yet again to ignore the weeks of back and forth with purchasing, who won’t understand what the tool does and nor they think the company needs it because it’s “just another piece of software.”

Congratulations! You’re magically past those ulcer-inducing stages. NOW you – the beleaguered IT person – are on the hook to:

Inventory all the systems that will be part of the pilot program.
Set up a QA environment for the new software, against the QA environment of the new application.
Explain to the vendor that you actually need TWO copies of the software, not one, and no you don’t have budget to pay for it twice, you need a free copy because it’s just QA.

Once again, we’ll pretend the vendor just say “duhhhh okay!” (spoiler: they rarely say that). Next on the list is to:

Install and configure the new vendor’s software.
Add the QA environment systems into the environment.
Manage and monitor the test, showing results to the application owners to prove your new software won’t destroy their app.

Once you’ve passed those items, the work is not done. You now have to:

Set up the new vendor’s software in the production system.
Add (not migrate) the application(s) to the new system.
Run the new system in parallel with the old one for a number of weeks, reporting comparative results to everyone up to the CFO’s father’s, brother’s, nephew’s, cousin’s, former roommate about how it’s going.
After that period, you can start to turn off (not delete, just turn off) the old vendor’s software. Note that your company is still PAYING for the old software, so exactly ZERO savings have been achieved. Try explaining THAT to the CFO.
During all of this, you are also responsible for re-creating all of the tests, alerts, reports, and dashboards in the old system that people now “desperately need” (even though they haven’t touched them in 2 years.)

Scroll back and review all those bullets one more time. Ask yourself what it would take to make you want to do that on top of your existing work. Most IT folks go through that kind of experience ONCE, often because they don’t realize what they’re in for. After that, most learn their lesson and stop asking about (or for) new tools because very little would be worth all (or any) of that.

“But Leon, companies DO aquire new tools. All the time. How do you explain THAT?”

Final spoiler: We wait for something to explode. We wait for a system we know is unstable to experience a surface-of-the-sun hot nuclear melt down. Because at that point, all the hurdles and bullshit clear away. The executives who were so picky before are now screaming bloody murder. They’ll do ANYTHING, agree to ANYTHING, to make sure that EXACT PRECISE problem never happens again,

Then and only then can a tool be adopted quickly.

This is why we can’t have nice things. Or at least, this is why IT folks don’t jump up and down with joy when you suggest they migrate to a new monitoring tool, despite their frustration with the current one.

So don’t be surprised when they don’t.

Cribl: Telemetry Gatherers

Leon Adato — Mon, 31 Aug 2026 17:00:00 +0000

(CriblCon is a month away, so I wanted to share a post - NOT about Cribl, or telemetry, or tech - but rather about the ways we IT folks sometimes find to combine whimsy and IT)

Honestly, it started off as a silly, wild-assed idea.

"Wouldn't it be funny if we made some Magic the Gathering cards that use Cribl products as spells, and maybe some of the problems our users have as monsters! We could give them out for a laugh in the booth. “

The problem - if you can really call it a problem - is that everyone at Cribl is really proud of our geeky heritage, and that includes MTG. We couldn't just joke about that idea. We had to jump in with both feet, burning our evening hours creating an ENTIRE FSCKING PLAY-ABLE SET. With boosters. And specialty cards. And counters. And… stuff.

From that initial silly wild-ass idea, things just snowballed. We quickly realized Cribl products (and not JUST products - other aspects of the Cribl solution) weren't spells. They were artifacts! Lands! Enchantments! We had to come up with mechanics for pipelines and replay. And we needed to create artwork for the cards.

SO. MUCH. ARTWORK.

To speed things up, Justin des Lauriers (once of our engineers, of course) created a whole-ass Gemini "gem" that would streamline creating card mechanics from a simple prompt.

And of course, once we had them, we had to playtest them. A lot. In multiple sessions that ran long into the night. Because we care. About authenticity. About game balance. But mostly, we care about maintaining the highest level of geek credibility we can have, and if it means forgoing sleep or proper hygiene, so be it!

We had a metric crap-tonne (that is a very technical measurement, by the way) of fun.

But as we played, we realized these cards could also teach people how Cribl did.

It might not be as good as Cribl University (OK, it definitely isn’t. Check them out at https://cribl.io/university/) but if you want to get some concepts in your bones in a fun and off-beat way, you could do a lot worse.

This should come as no surprise to anyone who has taught professionally (massive props to all the teachers out there!). It’s been clear for a long time that we all - adults as well as kids - learn better and retain information longer when it’s presented and experienced as a form of “play”. We sing the ABC song to memorize the alphabet. We have blocks, legos, and erector sets to learn spacial skills. We play dodgeball to learn to avoid flying wrenches.

And now we can tell our loved ones that we have to play Magic the Gathering in order to build our skills in Cribl and uplevel our career. Which will earn us a raise. With which we can buy more MTG cards. It’s the circle of life, but for nerds.

My point in all of this is two fold:

You absolutely positively need Cribl’s Magic the Gathering card additions in your deck.
Having these cards indisputably proves your credibility as an IT practitioner, a Cribl expert, and a geek.

Where can you find them?

We’ll be handing them out at conferences, CriblConnects, and of course CRIBLCONNNNNNNN! We will be looking for even more ways to share the MTG joy with the world in upcoming weeks and months.

Monitoring versu… I mean AND Observability

Leon Adato — Mon, 31 Aug 2026 14:00:00 +0000

Chapter 3 of the O’Reilly book I’m co-authoring with Kentik CEO Avi Freedman is out today (you can download it here: https://www.kentik.com/go/ebook/oreilly-guide-to-modern-networking-telemetry/ and I wanted to share a bit that didn’t make it through the editing process, because even with the eBook edition, space (and reader attention) isn’t infinite.

Nevertheless, I thought the longer version was worth a look, for some of the points it made.

In the book, we wrote:

In blog articles you’ll see the phrase “reason about”, as in “its more data than one person can reason about”, which is a fancy way of saying “keep it all in your head enough to be able to find patterns”. I mention this because one differentiations between “observability” from “monitoring” is not just the sheer volume of data, but also the disparity of that day that makes it difficult, if not impossible, to reason about it.

But here’s the longer version that we had to cut down:

In order to really appreciate how Machine Learning (ML) and AI can improve observability, it’s necessary to (briefly) differentiate between it (meaning: “observability”) and “monitoring”.

Monitoring is mostly concerned with “known unknowns”, by which I mean the things we know COULD potentially fail, but we don’t know WHEN. It’s comparatively trivial to understand what data needs to be collected, reported, and alerted on because we know where to look. Monitoring isn’t concerned with how unique the data is (i.e. “cardinality”) – whether we’re talking about an individual data point or a collection/grouping/slice of that data. And because of the two previous points (known unknowns and cardinality), correlation is usually manual – meaning humans who understand the combination of elements that indicate something is wrong are needed to craft the trigger for an alert or other action.

Observability, on the other hand, is more biased toward “unknown unknowns” – we don’t know what could go wrong and we also have no idea when that failure might occur. That ties into observability’s focus on “high cardinality” data – when specific data points or various permutations have never (or rarely) been observed. To achieve this, massive amounts of data need to be collected, normalized, parsed, and pivoted to find those unique combinations. And because of those two things (unknown unknowns and cardinality), correlation cannot be trusted to a human. There is simply too much data, and too many possible combinations of that data, to “reason about” it (to use phrase popularized by Charity Majors and Liz Fong-Jones).

This is a comparison I make often when I’m giving conference talks – NOT because I think I have the One True Definition (far from it) but rather because I want folks to have the proper context.

One additional point I make on both sides is “signals” – the data elements used to determine if the object of monitoring is healthy or not.

In “traditional” monitoring, signals are domain-specific. The data points that tell you a network device is not performing well are measurably different from those that indicate a database is unhappy. Or a block of code. Or even a wifi environment.

Meanwhile the philosophy of observability tries to standardize on the “Four Golden Signals” as established in the SRE Handbook – namely Latency, Traffice, Errors, and Saturation.

To be clear: the title of this blog is a misnomer. It’s not (and never was) “versus”. Monitoring and Observability should be seen as a BOTH-AND rather than EITHER-OR proposition.

With all that said, here’s a screenshot of the slide I use in my presentations, which lays it out (without the talk track). I hope you find it useful.