Forem: Philip Hern

on the plane, again

Philip Hern — Sun, 26 Apr 2026 22:35:23 +0000

thesis

my opinion on using wifi on a plane has shifted. i do not think it is the right default for everyone in every situation, but when i am traveling alone, especially for work, i have started to treat a connected cabin as a feature. it takes hours that used to feel like pure waiting, time i was just trying to burn through, and turns them into a stretch where i can work with a surprisingly solid level of focus and relatively few distractions.

context

a few weeks ago i wrote about how torn i still was on this topic in plane wifi: when the cabin forced disconnect. that piece was an honest inventory of the tradeoffs. this one is an update from the other side of the choice, after i have spent more flights actually buying the pass and sitting down to work instead of debating it.

argument

when i am alone and the trip is for my job, the row stops feeling like a cage and starts feeling like a quiet room with bad legroom. i already have headphones in, so the cabin noise is under control. notifications are fewer than at my desk, nobody is making noise by my office door, and the margin of "things i could be doing instead" feels narrower. it is not peace and it is not deep rest, but it is a usable kind of concentration.

i am now using that block to write, to debug, to plan, and to close loops i would otherwise push to after i land. i go in knowing i will get a meaningful amount done, and that expectation makes the clock feel less stuck. the time still passes at the same speed, but it passes with output attached, and that changes how it feels in my body.

i also have a concrete proof point that this mode is not just talk. i completely stood up my personal website while airborne, end to end, in one of those sessions. right now i am on a plane again, getting ahead for an in-person meeting so i can walk in prepared instead of scrambling on the jet bridge.

tension or counterpoint

i am not arguing that every person should pay for wifi on every flight. shared trips, family logistics, the middle seat, motion sickness, or the simple need to be offline are all good reasons to skip it. economy is still a bad default office for anyone who needs space or quiet that the cabin cannot give. my point is narrower. for me, in the situations where it fits, the cost of the pass is cheaper than the opportunity cost of treating the whole flight as lost time.

closing

i will probably still sometimes want the cabin to be an excuse to be unreachable. when i do, i can leave the wifi off. when i do not, i am glad the option exists, and i am using it on purpose.

related on this site

logic

Philip Hern — Sun, 26 Apr 2026 22:35:21 +0000

thesis

learning basic logic is one of the most useful, durable skills i can recommend to anyone, regardless of profession. the english-language version of if/then/else is a thinking tool that works everywhere, never expires, and quietly compounds into better decisions over a lifetime.

context

most people associate logic with code, math, or a philosophy classroom. that framing is too narrow. logic is just structured cause-and-effect thinking, and the simplest version of it sounds exactly like english:

if this, then that, else that other thing

once you can hold that pattern in your head on purpose, it changes how you plan, diagnose, design, and interpret almost everything in front of you. you do not need a programming language to use it. you just need to be willing to slow down for a beat and think in branches instead of straight lines.

a few familiar gates

here a few small pictures to demonstrate simple examples of logic gates that you already use in daily life. this just illustrates it so you can literally follow along with the logic gates as each situation progresses.

and both must be true for the outcome to be true
or at least one true is enough
not you follow the opposite branch of the test

the flow is the same kind of small chart you would sketch on a napkin.

{{< mermaid >}}
flowchart TB
subgraph g_and [and, both need to be true]
direction LR
w[good weather?] --> and1{and}
f[afternoon free?] --> and1
and1 -->|yes| hike[go hiking]
and1 -->|no| home[stay in]
end
subgraph g_or [or, at least one is enough]
direction LR
car[friend can drive?] --> or1{or}
bus[transit is running?] --> or1
or1 -->|yes| go[you can get there]
or1 -->|no| stuck[you are stuck]
end
subgraph g_not [not, the opposite branch of the test]
direction LR
pow[power on?] -->|no| br[check the breaker]
pow -->|yes| next1[next check in the chain]
end
{{< /mermaid >}}

none of that requires a keyboard. it is the same branch habit as the if/then/else line in the last section, just drawn with a few boxes.

argument

logic is a thinking tool, not a coding tool

the if/then/else pattern is older than any programming language. when i write a small script, i am formalizing the same branching i already do when i pick what to wear, route around traffic, or decide how to respond when something at work breaks. the keyboard is incidental, the structure is the point.

this kind of structured thinking is what moves me from "i feel stuck" to "what is the next decision, and what are the branches under it". that small shift, from a vague feeling to a concrete branch point, is where most of the leverage comes from.

where it pays off in normal life

once you start noticing branches, you see them everywhere. planning a day with kids becomes a small logic tree. if the weather holds, we hike. if it does not, we move to the indoor option. if both fail, we cancel and reschedule. naming the branches up front means the day does not collapse when conditions change.

troubleshooting has the same shape. when something is not working, i walk a tree out loud. if the appliance has power, then check the next link. if not, then check the breaker. each step rules out a branch and shrinks the search space.

designing a process at work has the same bones. i list the conditions first, then the path each one takes. naming the branches early makes the design easier to explain and easier to fix later.

understanding behavior is harder, but the structure still helps. people are not perfectly logical, but their patterns often are. if my kid is tired, then certain tantrums become more likely. if a colleague is overloaded, then certain reactions track. recognizing the antecedent makes the response less personal and easier to handle.

reverse engineering is the same thing run backward. when i look at a result and want to understand how it got there, i walk the logic in reverse. if this output exists, then these inputs and conditions must have been true. if not, then the model i had in my head is wrong, and that gap is useful information on its own.

the tool never goes out of style

frameworks change. tools change. programming languages come and go. if/then/else does not. it is a structure of thought, not a piece of technology, which is why it keeps working in domains it was never designed for. cooking, parenting, negotiations, medical decision trees, customer support scripts, and legal arguments all lean on the same scaffolding.

i find real comfort in skills that age well. so much of what i learn in tech has a short half-life now. logic does not. once i have it, i have it for good.

applying it broadly is what makes it powerful

a tool that works in one place is useful. a tool that works everywhere is leverage. logic works everywhere because every domain has cause and effect, conditions, and outcomes. that generality is the multiplier, and it is the same kind of cross-domain value i wrote about with adaptability. the principle stays steady while the surface details swap.

learn it as early as you can

the earlier this gets internalized, the more downstream decisions inherit it. a kid who can think in branches asks better questions, accepts fewer "because i said so" answers, and gradually builds a habit of checking conditions before reacting. that habit then runs in the background for the rest of their life.

i think about this with my own kids, and i think about it for myself. every year i wait to make decisions more deliberately is a year of slightly noisier decisions stacked behind me.

the butterfly effect of better decisions

small improvements in single decisions do not look like much in isolation. two paths that differ by one degree at the start can end up far apart over a long enough timeline. better daily decisions, even by a thin margin, compound the same way a little becomes a lot does for habits. the quality of the inputs, repeated across years, becomes the quality of the life.

logic is one of the cheapest ways i know to nudge that compounding in a good direction.

tension or counterpoint

logic on its own is not the whole answer. real situations carry emotion, ambiguity, missing information, and people who do not behave according to clean rules. if i treat every interaction like a flowchart, i lose intuition, empathy, and the ability to sit with uncertainty.

the skill is to use logic as scaffolding, not as a replacement for judgment. i map the branches i can see, then i listen for the part that the branches do not capture. both layers matter, and the logical part actually helps the intuitive part by giving it a clean place to stand.

closing

this is one of the cheapest, most durable investments anyone can make. learn the english-language form of if/then/else. practice naming the conditions and the branches in your own life. apply it to planning, troubleshooting, designing, and understanding the people around you.

learn it once and you keep it forever. apply it everywhere and it compounds. not many skills pay back like that.

related on this site

back at it

Philip Hern — Thu, 23 Apr 2026 12:27:13 +0000

thesis

this is a small checkpoint post. the heavy lift is not finished, but i am out of the weeds for now, and that is worth naming out loud.

context

the same work i was carrying in stick with it kept growing in weight and surface area. for a while it felt like one endless tangle. i stayed with it anyway, and eventually i approached it the way i should have from the start, as smaller chunks that stack into the much larger change. each piece still had to be real, but the sequencing and scope finally matched how my head and the system can tolerate change.

argument

getting to a stable point did not erase the backlog. i still have more testing to run, more simulations to exercise, and real user acceptance testing ahead. the difference is that the foundation is no longer thrashing. errors and surprises have a place to land without undoing everything at once.

that stability is what gave me room to breathe. i can take a short break on purpose, look at the whole arc with a little distance, and come back to the tuning work with less panic and more optimism. the remaining work is still serious, but it is the kind of serious that fits a calendar instead of the kind that owns every waking hour.

tension or counterpoint

a stable checkpoint is not the same as done. if i confuse relief for completion, i will skip validation i still need. the discipline now is to rest without pretending the job is closed.

closing

so i am back at it in a different posture, not firefighting the whole shape at once, but finishing the test matrix, listening to users, and dialing things in with a clearer mind. sticking with it got me here. the next stretch is about proving it in the world, calmly.

related on this site

stick with it

Philip Hern — Fri, 17 Apr 2026 13:24:41 +0000

thesis

this one is for me as much as anyone reading. the single most important thing i can do on a long, hard project is keep showing up for it. motivation rises and falls, energy comes in waves, and neither of those things matter as much as continuity. if i stay with the work long enough, the payoff arrives, even when progress is invisible for stretches in the middle.

context

i am in the middle of a very heavy lift right now. it started as a change i thought i would finish quickly, and it has turned into something much bigger. the effort, concentration, and validation required are more than i am used to, and the timeline has stretched well past what a typical change would take. the stress is real. i feel it in how i think about the project before bed and how quickly i reach for my laptop in the morning.

i am still in it, though, because the value at the end is worth the cost. when this lands, i will have more stable and explainable historical data, which means my ongoing workload of troubleshooting data validity questions drops. less firefighting later is worth more pressure now, and that tradeoff is the only reason i would keep going through a change this heavy.

argument

continuity beats intensity

motivation is a wave, not a rope. it pulls me forward for a while, then it lets go, then it comes back later with a different shape. if i tie my progress to the wave, i stop whenever the wave stops. if i tie my progress to the habit of showing up, the wave cannot take the project down with it. that is the same pattern i wrote about in little by little, a little becomes a lot, just applied to a single long problem instead of a daily practice.

isolate your changes, even in your own playground

the hardest lesson from this round is about isolation. i have been testing work in an environment i consider my playground, and for a long time that has been fine. this time, my changes broke downstream consumers, and the pressure immediately escalated because other people were suddenly blocked. the takeaway is simple. if my changes can reach downstream consumers, i need to separate my testing from a shared test environment, regardless of how freely i am used to moving in that space. a playground still has neighbors.

do not try to lift several objects at once

i also tried to move multiple pieces of the system at the same time. i thought bundling them would be faster. what actually happened is that each piece depended on the others in a way that made every single one harder to validate, and the total stress grew faster than the total work. smaller, sequential chunks would have finished sooner and felt calmer. one object at a time, even if it feels slower on paper, is almost always faster in practice.

better preparation shrinks the stress

the last lesson is about preparation. i went in expecting a small change and i prepared like it was a small change. when the scope grew, my preparation did not grow with it, and that mismatch is where the break points appeared. better preparation up front, regardless of how small i thought the task was, would have reduced both the stress and the number of places things could go wrong. the cost of preparing for a bigger job than you need is tiny. the cost of not preparing for the job you actually have is not.

tension or counterpoint

persistence is not the same as refusing to reassess. sticking with every hard thing forever is just sunk cost fallacy wearing a motivational t-shirt. the honest check i keep running is whether the value at the end is still real and still mine. if the answer is yes, i keep going. if the answer turns into no, i stop, and that is not quitting, that is discernment.

there is also a stress cost to "push through" language. if the pressure is spilling into health, relationships, or judgment, that is a signal to change the pace, not a signal to try harder. pushing through is a tool, not a strategy, and it only works when i also rest and isolate the work properly. that is part of why i think it helps to get comfortable being uncomfortable without confusing discomfort for permission to keep grinding.

closing

so this is my note to myself. keep going. the work is real, the value is real, and the lessons i am collecting on the way are already paying off for the next change. next time i will isolate my testing better, break the work into one object at a time, and prepare like the task is bigger than i think it is, because it almost always is.

and if the wave of motivation dips again tomorrow, that is fine. waves dip. what matters is that i still show up, finish one more piece, and trust that continuity is the actual engine. stick with it.

related on this site

comfortable being uncomfortable

Philip Hern — Fri, 10 Apr 2026 19:29:32 +0000

thesis

i want to normalize a simple idea that still feels hard in practice. getting outside of your comfort zone is not a side quest. it is the main mechanism by which you stretch, learn, and see the world with more room in it for other people. yes, it is uncomfortable, and that is exactly the point.

context

most of us are trained to seek stability. stability is not bad, but it is also not where the adaptation happens. when everything feels familiar, your brain is mostly rehearsing what it already knows. the moment you step into something new, the cost shows up immediately as awkwardness, uncertainty, or fear of looking foolish. that friction is not a sign you chose wrong. it is often a sign you chose honestly.

argument

change is disruptive by definition. if it did not interrupt your default patterns, it would not be change. i think we should embrace that disruption more often, because it is where new experiences actually enter your life. without that interruption, you mostly get repetition with better packaging.

the growth part is not theoretical. discomfort is where skills get pressure-tested. you learn not only how to do things, but how not to do things, which is just as valuable and often faster feedback. mistakes in public or under stress are expensive emotionally, but they are also unusually clear. they show you boundaries, preferences, and limits in a way that a comfortable afternoon rarely will.

more experiences also broaden your worldview in a practical sense. when you have seen more contexts, constraints, and ways people solve problems, it becomes harder to treat your own habits as universal law. that widening tends to produce more tolerant and compassionate attitudes, not because tolerance is a slogan, but because you have more firsthand evidence that reasonable people can live and work in very different, equally valid ways.

so my encouragement is simple. expose yourself to new experiences on purpose. seek situations where the pressure is on you to perform, because that is where you rise to the occasion and discover how capable you can be. it is also where you might discover that this is not your thing, and you should move on. either outcome is a win, because both give you self-insight you cannot fake. you learn what energizes you, what drains you, and what you are willing to practice until it gets easier.

this connects to how i think about adaptability in general. comfort is a resting state. adaptation requires movement.

tension or counterpoint

there is a real downside to glorifying discomfort without boundaries. not every challenge is worth the cost, and not every "growth opportunity" is ethical or safe. pushing yourself is different from letting yourself be pushed past your values or health. the goal is not suffering for its own sake. the goal is chosen stretch, with recovery and discernment built in.

closing

i am not asking for constant chaos. i am asking for a bias toward the new when you can afford it, and toward the high-stakes try when you are ready. the uncomfortable path is where you find out who you are when the easy defaults are not available, and that knowledge is about as practical as it gets.

related on this site

dbt snapshots: moving from merges to native history

Philip Hern — Fri, 10 Apr 2026 19:29:31 +0000

quick answer

dbt snapshots provide a native way to track slowly changing dimensions over time. by migrating from custom merge statements to native dbt snapshots, you can simplify your codebase, rely on built-in history tracking, and ensure your downstream models always have access to point-in-time records.

who this is for

audience: data engineers and analytics engineers using dbt
prerequisites: basic knowledge of dbt models, sql, and data warehousing concepts
when to use this guide: when you need to track historical changes to mutable source records and want to move away from manual merge logic

why this matters

tracking historical changes is a common requirement in data warehousing. building custom merge logic to handle inserts, updates, and history tracking is error-prone and difficult to maintain. dbt snapshots handle the heavy lifting of history tracking out of the box. this ensures you do not lose historical context when source systems overwrite data.

moving from merge to snapshot

recently, i migrated several historical tables from a custom merge strategy to native dbt snapshots. the previous approach relied on complex merge statements that manually checked for changes and inserted or updated rows to maintain history. this was difficult to read and even harder to debug.

by adopting native dbt snapshots, the logic became declarative. instead of writing the exact update and insert commands, i only needed to define the source query and configure how dbt should detect changes. the downstream consumer views then filter the snapshot output to return the current row or a point-in-time record.

the core shift in thinking

when using snapshots, your snapshot definition should remain source-representative. do not apply business date-window filtering in the snapshot definition itself. instead, capture the raw history and apply your logic for which rows to return in downstream consumer views.

for example, to get the current row in a downstream model, you filter using the sentinel value:

select *
from {{ ref('my_snapshot_st') }}
where dbt_valid_to = '9999-12-31 23:59:59'

to get a freeze record for a specific point in time, you derive a freeze timestamp and filter:

select *
from {{ ref('my_snapshot_st') }}
where dbt_valid_from <= freeze_ts and dbt_valid_to > freeze_ts

basic example

here is a basic example of a dbt snapshot using the check strategy. this snapshot tracks changes to a practice affiliation table.

{% snapshot practice_affiliation_st %}

{{
    config(
        target_schema = 'snapshots',
        strategy = 'check',
        unique_key = ['fmno', 'cycle', 'committee', 'hierarchy'],
        check_cols = 'all',
        hard_deletes = 'invalidate',
        dbt_valid_to_current = "to_timestamp_ntz('9999-12-31 23:59:59')"
    )
}}

select
    fmno,
    cycle,
    committee,
    practice_name,
    type,
    hierarchy
from {{ ref('source_practice_affiliation_v') }}

{% endsnapshot %}

configuration options

dbt snapshots offer several configuration options that control how changes are detected and recorded. you can read more about these in the official dbt snapshot documentation.

here are the key options and what they control:

target_schema: the schema where the snapshot table will be built
strategy: determines how dbt detects changes, with the two main options being timestamp and check
unique_key: the primary key of the record, which can be a single column or a list of columns for a composite key
check_cols: used with the check strategy to specify which columns to monitor for changes, accepting a list of column names or the word all
updated_at: used with the timestamp strategy to specify the column that indicates when the source row was last modified
hard_deletes: controls how dbt handles rows that disappear from the source, such as setting it to invalidate to close the current row when a key is no longer present
dbt_valid_to_current: overrides the default null value for current records, allowing you to set a far-future date to make downstream filtering easier

timestamp vs check strategy

the choice between timestamp and check strategies is critical.

use the timestamp strategy when your source has a reliable updated column that changes whenever the row changes. dbt compares the source timestamp to the snapshot timestamp to decide if a new version is needed.

use the check strategy when you do not have a reliable updated timestamp, or when you want to detect any change in a specific set of columns. dbt compares the actual values of the check columns between the source and the current snapshot row. if any checked column differs, dbt closes the current row and inserts a new version.

in my recent work, i found that the check strategy with all columns checked and a composite unique key was the most robust approach for sources where the updated timestamp was synthetic or not authoritative.

gotchas and lessons learned

migrating to snapshots surfaced a few important lessons:

upstream scope gating: if your upstream source query includes filters that remove keys, and you have hard deletes configured to invalidate, dbt will intentionally close the current rows for those missing keys
composite keys: dbt fully supports composite unique keys, and passing a list of columns ensures that dbt tracks history at the correct grain
duplicate source rows: snapshots expect the source data to be unique at the unique key grain, so if your source contains duplicate keys, the snapshot will fail or bloat
defensive deduplication: in some cases, i had to add a defensive qualify row number guard in the snapshot definition to collapse known duplicate-key source rows before dbt processed them
sentinel values: using a sentinel value for current rows instead of null makes downstream queries much cleaner, allowing you to use an equals operator instead of checking for nulls

deployment and automation

snapshots are not updated automatically when you run your standard dbt build commands. they require a dedicated command: dbt snapshot.

if you do not automate this, your history tracking will be manual and prone to gaps. to ensure continuous history capture, you must schedule the snapshot command to run on a regular cadence.

in a production environment, this usually means setting up a continuous integration workflow or an orchestrator task. for example, you can use automated workflows to run snapshot tags on daily, hourly, or monthly schedules.

a typical automated workflow might look like this:

a scheduled trigger fires the workflow
the workflow checks out the repository and sets up the dbt environment
the workflow executes the snapshot command for specific tags
dbt connects to the warehouse, compares the source data to the existing snapshot tables, and applies any necessary inserts or updates

by decoupling the snapshot schedule from your standard model runs, you can capture history at the exact frequency your business logic requires.

references

little by little, a little becomes a lot

Philip Hern — Tue, 07 Apr 2026 23:13:24 +0000

thesis

the importance of just trying to do a little each day cannot be overstated. we often overestimate what we can accomplish in a single afternoon, but we vastly underestimate what we can build over a year of sustained effort. incremental changes add up, and what seems like a drop in the bucket today becomes a reservoir over time.

context

whether it is work, fitness, or building new routines, habit forming often feels like it takes forever to take hold. we live in a world that expects immediate results, and we naturally get frustrated when the scale does not move or the project does not finish overnight. when that initial burst of motivation inevitably fades, the reality of the daily grind sets in, and that is exactly when most people decide to walk away.

argument

this process is a little easier when you understand you are working toward continuity and not perfection. it is not about executing flawlessly every single day, nor is it about never taking a break. it is about showing up and putting in the reps, even when the effort feels small or uninspired. missing one day is just a bump in the road, as long as you do not let it become two days in a row.

i am starting to see the rewards of that mindset now. little by little, my experience has added up into a foundation i can actually rely on. little by little, i have started sharing via my website, turning scattered thoughts into a structured body of work. little by little, i am starting to have a greater reach and help more people, simply because i chose to publish something small rather than waiting for the perfect masterpiece.

tension or counterpoint

the hardest part is trusting the process when the visible progress is zero. it is incredibly easy to quit when you do not see the immediate payoff of your daily effort. it feels like you are just watering dirt for weeks on end. but the compounding effect of showing up is real, even if it remains completely invisible in the short term.

closing

so right in theme, i will keep this short and keep focusing on the small, daily inputs rather than the distant outputs. the goal is simply to keep the chain going, trusting that a little becomes a lot when you give it enough time.

related on this site

how i automated dev.to and linkedin publishing so visibility stops depending on memory

Philip Hern — Sun, 05 Apr 2026 14:03:19 +0000

after i started writing more consistently, it became obvious that writing is only half the work; distribution is the other half. i wanted a system where i can publish from one canonical source and let automation push the same story to dev.to and linkedin.

quick answer

i set up two publish automations that watch my post changes and sync them to dev.to and linkedin. the first publish creates the post on each platform, and later edits update the same external post instead of creating duplicates. this gives me consistent visibility without adding manual publishing steps after every article.

who this is for

people who publish technical writing and keep forgetting cross-posting
creators who want one canonical source plus repeatable distribution
builders who care about discoverability as much as writing quality

why this matters

if distribution is manual, it eventually slips. then strong posts sit unread because i forgot to copy, paste, format, and re-share them across platforms. automation solves that by making visibility part of the same delivery path as the content itself.

this is the same pattern i described in a practical ai workflow: jira, github, and mcp, define one clear source of truth, then automate the handoff steps so i can spend more time on thinking and less time on clerical work.

step-by-step

1) define the starting point

i chose my site post as the only canonical source. every external platform receives content from that source, not from separate drafts. this keeps language, links, and updates aligned over time.

2) apply the change

i added automation for both targets:

trigger on post updates and support manual runs when i want a full backfill
create posts when no external mapping exists
update existing external posts when a mapping already exists
keep a small state map so each canonical url stays attached to one external post id

the practical result is that i can keep writing in one place and trust the sync layer to handle distribution. this complements the writing habits from my cursor setup, where reusable workflows remove repeated manual work.

3) validate the result

i test in three passes:

dry run to confirm detection and decisions without publishing
publish-all run to verify initial backfill behavior
normal change-trigger run to verify incremental updates on later edits

when all three pass, i know the pipeline is reliable enough for daily use.

faq

what was the biggest setup mistake?

token and redirect mismatches during oauth were the main failure point at first. once i aligned scopes, callback values, and secret placement, the automation became stable.

should i keep manual publishing as a fallback?

yes, especially while you are in early setup. after the workflow proves stable, manual publishing becomes a recovery path instead of a default habit.

references

the future of data engineering workflows with ai

Philip Hern — Fri, 03 Apr 2026 14:11:59 +0000

quick answer

the future of data engineering workflows with ai is about moving from manual coding to intelligent orchestration. ai agents will handle boilerplate code, pipeline generation, and data quality checks, allowing data engineers to focus on architecture, governance, and business value.

who this is for

audience: data engineers, analytics engineers, data architects, and technical leaders.
prerequisites: an understanding of modern data stack concepts and basic ai principles.
when to use this guide: when planning your data strategy and evaluating how to integrate ai into your engineering practices.

why this matters

the volume and complexity of data are growing faster than engineering teams can scale. relying solely on manual workflows leads to bottlenecks, technical debt, and delayed insights. embracing ai is not just about efficiency, it is a strategic imperative to remain competitive.

step-by-step

1) define the starting point

traditionally, data engineering has been a highly manual discipline. engineers spend countless hours writing sql, configuring orchestrators like airflow, and debugging failed pipelines. this approach is brittle and scales poorly as the organization grows.

2) apply the change

the integration of ai changes this paradigm. large language models can now generate complex sql queries, translate between dialects, and even suggest optimal data models based on source schemas. ai agents can monitor pipeline health, automatically retry transient failures, and alert engineers only when human intervention is necessary. this shift transforms the engineer from a coder into a system architect.

3) validate the result

the impact of this transformation is measurable. development cycles shorten, data quality improves through automated testing, and the overall reliability of the platform increases. engineers spend less time firefighting and more time building scalable, resilient architectures that drive business decisions.

faq

what is the most important caveat?

ai is a tool, not a replacement for fundamental engineering principles. you still need a strong understanding of data modeling, governance, and security to build a robust platform.

what should i do first?

start by identifying the most repetitive tasks in your workflow, such as writing documentation or basic transformations. experiment with ai tools to automate these specific areas before attempting to overhaul your entire architecture.

references

the modern data stack

how i use cursor and ai agents to write dbt tests and documentation

Philip Hern — Fri, 03 Apr 2026 14:07:49 +0000

quick answer

writing dbt tests and documentation is often the most neglected part of data engineering. i use cursor and custom ai agents to automate this process by reading my sql models, inferring the business logic, and generating the corresponding yaml files. this ensures high-quality data pipelines without the manual overhead.

who this is for

audience: data engineers, analytics engineers, and developers using dbt
prerequisites: basic knowledge of dbt, sql, and cursor
when to use this guide: when you want to scale your data engineering practices and reduce the time spent on writing boilerplate yaml

why this matters

documentation and testing are critical for data trust, but they are tedious to write manually. when these steps are skipped, data quality suffers and debugging becomes a nightmare. by automating this with ai, you get the benefits of rigorous testing and clear documentation while freeing up your time for higher-value architectural work.

step-by-step

1) define the starting point

most data engineers start with a raw sql model and a blank slate for their schema.yml file. the traditional approach requires manually typing out every column name, description, and test. this is prone to human error and inconsistency, plus almost always falls out of sync with current models with the first change.

2) apply the change

i use cursor to bridge this gap. by creating specific ai rules and skills, i can highlight a dbt model and ask the agent to generate the documentation. the agent reads the sql, understands the joins and transformations, and produces a complete yaml file with standard tests like not_null and unique. it can even infer complex relationships and suggest custom tests based on the data domain.

3) validate the result

once the ai generates the yaml, i review it for accuracy. i then run dbt test and dbt docs generate to ensure everything compiles correctly. the ai rarely makes syntax errors, so the validation step is mostly about confirming the business logic aligns with the documentation.

faq

what is the most important caveat?

you must still review the generated output. ai is excellent at scaffolding and inferring patterns, but it does not possess the full business context that you do.

what should i do first?

start by creating a simple cursor skill that defines your team's standards for dbt documentation. feed it a few examples of your best schema.yml files so it learns your preferred style.

references

dbt documentation

sharing is caring

Philip Hern — Thu, 02 Apr 2026 12:11:05 +0000

the value of early adoption

i have always found a unique kind of energy in being an early adopter. when a new tool emerges, especially something as transformative as cursor and artificial intelligence, diving in headfirst is not just about personal efficiency. it is about understanding the landscape before the map is fully drawn. by spending the hours required to become a high-level user, i build a deep familiarity with the edges of what the technology can do.

this mastery translates directly into value for my colleagues. when you understand the high-level nuance of a complex tool, you naturally become the point person for your team. people have onboarding questions, they hit roadblocks, and they need someone who has already navigated those early frustrations. being that resource is incredibly rewarding. it shifts my role from an individual contributor to a multiplier, helping the entire team elevate their workflow and avoid the pitfalls i have already solved.

the responsibility to share

this dynamic reminds me of a principle i have heard often over the years regarding the importance of using your voice and your platform to share. this is exactly why i started this website. i wanted a dedicated space to share my voice, my knowledge, my opinions, my experience, and the solutions i have discovered along the way.

when you hold onto knowledge, its impact is limited to your own output. when you share it, the impact scales infinitely. writing about these tools, documenting my workflows, and answering the nuanced questions my colleagues ask are all extensions of the same core belief. knowledge is meant to be distributed.

stepping into mentorship

i have reached a point of mastery and experience where the natural next step for me is to mentor others and deliberately increase my visibility and presence. it is no longer enough to simply be good at what i do behind the scenes. the real work now is in lifting others up.

in fact, i am starting to feel the weight of this realization. it feels almost selfish not to share what i have learned. when you spend years honing a craft or mastering a paradigm-shifting tool like ai-assisted development, you accumulate a wealth of invisible context. keeping that context locked away serves no one. stepping into a mentorship role, both directly with my colleagues and publicly through this platform, is how i honor the effort it took to gain that experience in the first place.

looking forward

my goal is to continue exploring the bleeding edge of these tools, but with a renewed focus on how i can translate those discoveries into accessible guidance for others. whether it is through answering a quick onboarding question about cursor, writing a detailed guide on this site, or simply being a sounding board for a colleague, the objective remains the same. i want to use my experience to make the path easier for those who follow.

related on this site

post title

what is art?

Philip Hern — Mon, 30 Mar 2026 23:38:30 +0000

thesis

i keep pondering lately, what are we actually defending when we say "ai art is not real art"?

i do not have a final position yet. i am writing this to think in public, not to close the debate.

context

while driving on a family vacation, i asked my wife to fulfill her duty as the passenger and dj some motown bangers. she searched on spotify and found something that seemed to fit the bill. most of the songs were recognizable, memories from my childhood, riding in the backseat listening to my parents' favorites. however, the first song on the playlist was by an artist called the 19s soulers, which was an artist i did not recognize. this was a user created playlist so not everything might fit perfectly into the motown mold i was asking for, and that was ok. the song started and it was SOOO good. TOO good. i had my suspicions, but the music caught me so hard that i completely forgot. i asked my boys in the back seat to look up the artist and they did not even search and just responded "AI DAD - IT IS AI". i felt so many conflicting emotions, including one of pride that my boys could tell the difference and they have some defense against being fooled.

the conversation around ai-generated images and music feels hotter every week, especially when a new ai music act gets attention or a contract. the reaction is often immediate and predictable outrage, fear, dismissal, and arguments about stolen style.

at the same time, many of us use ai to help write code, review pull requests, or shape architecture notes without the same emotional response. that contrast is interesting to me.

if i call code a craft, and sometimes an art form, then why does ai help feel acceptable there for so many people, but unacceptable when the ai helps write song lyrics? and if code can be expressive, why is the outrage concentrated in painting, illustration, and music.

my code has my fingerprints all over it, just as much as this website and the way i speak and write. it defintely qualifies as expressive. i make stylistic, logic, function, etc. choices that suit my style. how is this different from writing a book? but if you asked which one is acceptable to use ai and which one is not, i could guess your answer 99% of the time.

argument

i see a few possible reasons, and none of them feel complete on their own:

visual art and music are tied to identity in a very direct way
audiences often connect to the "maker story", not only the artifact
creative labor markets in those fields already felt fragile before ai
software teams have normalized tool-assisted output for decades
code is often judged by function first, while art is judged by intention and feeling

still, even with those differences, i cannot shake the inconsistency.

when i use ai in code, i still feel like the author because i set constraints, reject bad output, and own the result. i do not think that is very different from guiding a visual generator, editing outputs, and curating a final piece. maybe the difference is only social permission, not creative mechanics.

this question also links to my concern about ownership in the danger of trusting the ai agent, where speed is useful but responsibility still has to stay human.

tension or counterpoint

there is also a strong counterpoint i take seriously: in code, wrong answers fail in visible ways. tests fail, services break, users complain, and teams can trace accountability. in art, value is less binary, and that makes authorship feel more central and more vulnerable.

another counterpoint is economic, not philosophical. people may not be reacting to "is this art" at all. they may be reacting to "will this replace my livelihood".

both of those points feel real to me.

and i think the later point is one worth exploring because the wide-spread availability of ai has "democratized" creativity, technical endeavors, etc. for people who might have great ideas, but not the musical or technical skill to carry out the plan. well, now they do. and that instant competition that was not present before can certainly feel intimidating and encroaching.

i am currently mostly pro-ai, but with caution. we should have caution regarding how the models are being trained (and on what data) and regulated. we should exercise caution surrounding who is doing the regulating, as well. ai is a powerful assistant, and as we all know from spiderman, with great power comes great responsibility.

closing

i am left with questions, not conclusions.

maybe we value human touch most where we believe the human story is the product. maybe we accept ai more where we believe the product is utility. maybe those boundaries are changing and we are all reacting in real time.

for now, i am trying to keep the question open.....when ai is part of the process, what still makes something mine, yours, or ours?

Forem: Philip Hern

on the plane, again

thesis

context

argument

tension or counterpoint

closing

further reading

related on this site

logic

thesis

context

a few familiar gates

argument

logic is a thinking tool, not a coding tool

where it pays off in normal life

the tool never goes out of style

applying it broadly is what makes it powerful

learn it as early as you can

the butterfly effect of better decisions

tension or counterpoint

closing

further reading

related on this site

back at it

thesis

context

argument

tension or counterpoint

closing

further reading

related on this site

stick with it

thesis

context

argument

continuity beats intensity

isolate your changes, even in your own playground

do not try to lift several objects at once

better preparation shrinks the stress

tension or counterpoint

closing

further reading

related on this site

comfortable being uncomfortable

thesis

context

argument

tension or counterpoint

closing

further reading

related on this site

dbt snapshots: moving from merges to native history

quick answer

who this is for

why this matters

moving from merge to snapshot

the core shift in thinking

basic example

configuration options

timestamp vs check strategy

gotchas and lessons learned

deployment and automation

references

related reading

little by little, a little becomes a lot

thesis

context

argument

tension or counterpoint

closing

further reading

related on this site

how i automated dev.to and linkedin publishing so visibility stops depending on memory

quick answer

who this is for

why this matters

step-by-step

1) define the starting point

2) apply the change