<h1>ChatGPT for the Moms</h1>
<img src="/images/guggenheim.webp" alt="Spring has sprung, and Guggenheim shows it.">
My mom is a vi­o­lently in­tel­li­gent woman.
But she lives in the un­for­tu­nate re­al­ity of not be­ing a soft­ware en­gi­neer or math­e­mati­cian.
While she is just as ex­cited about ChatGPT (and all the other nascent AI tech­nol­ogy) as the rest of us, she is­n’t aware of the un­in­tel­li­gent pit­falls ar­ti­ﬁ­cial in­tel­li­gence has these days.
If your mom is ex­per­i­ment­ing with ChatGPT, I’d highly rec­om­mend send­ing this list to her.
Pow­er­ful tech­nol­ogy is in their hands, but I’ve got three things they should know be­fore re­ly­ing on it.
<h2>Advice for Moms</h2>
<h3>Use Web Search</h3>
My mother re­cently learned how to make cob­bler.
She adored asked ChatGPT ques­tions about the recipe, and how she could im­prove it us­ing the in­gre­di­ents she had on hand.
Un­for­tu­nately, she was get­ting sub­tly wrong in­for­ma­tion from the bot, so the cob­bler turned out “sub-par”.
This can be solved by us­ing ChatGPT’s web search.
When you open up ChatGPT on a phone or on a com­puter, you’ll be met with the fa­mil­iar chat win­dow.
If you ask it ques­tions it will give you an an­swer.
Some­times that an­swer will be good, some­times not.
You can gen­er­ally get bet­ter in­for­ma­tion if you en­able the web search tool.
<img src="/images/chatgpt_web_search_tool.png" alt="A screenshot of the ChatGPT web search tool.">
This will al­low ChatGPT to do Google searches on your be­half.
It im­proves the qual­ity of in­for­ma­tion it gives you, while only adding a sec­ond or two to their re­sponse.
<h3>It Is Not Your Friend</h3>
When we see a chat win­dow, our ﬁrst thought is that there’s a per­son on the other end.
Some­one with emo­tions and lives all their own.
That is not the case here.
ChatGPT, while an ad­vanced ma­chine learn­ing model, is not a per­son.
It does not re­place real hu­man con­nec­tion.
It can’t watch your kids when you’ve got an emer­gency.
It won’t show up to the school recital.
It does­n’t care about you—de­spite what it says.
There’s a lot that goes into a gen­uine so­cial con­nec­tion, all of which are miss­ing from ChatGPT.
<h3>Use Your Brain</h3>
ChatGPT is no sub­sti­tute for crit­i­cal thought.
It can­not do most things, even if it claims it can.
You are a ca­pa­ble hu­man be­ing—able to ac­com­plish any­thing you put your mind to.
While ChatGPT can be a help­ful as­sis­tant or brain­storm­ing part­ner, don’t let it steer the ship.
<h2>What to Remember</h2>
While ChatGPT can be a pow­er­ful tool in the right hands, it is im­por­tant to re­mem­ber it is just that: a tool.
It can be en­hanced with the right set­tings, it is not real hu­man con­nec­tion, and it can’t re­place your brain.
Use it well and use it wisely.

Advice you can give your mom (or other nontechnical person) for how to use ChatGPT wisely and effectively.

Advice you can give your mom (or other non­tech­ni­cal per­son) for how to use ChatGPT wisely and ef­fec­tively.

ChatGPT for the Moms

<h1>Always Think of the Hook First</h1>
<img src="/images/log.webp" alt="A log I found in the Indian Peaks Wilderness">
In his pop­u­lar book, Outliers, Malcolm Gladwell made the case that there was one num­ber that pre­dicted your skill level in a ﬁeld: the num­ber of hours of ded­i­cated prac­tice.
In pop­u­lar cul­ture, this idea has been sim­pli­ﬁed.
Some think that if you just do some­thing for 10,000 hours, then you’ll be­come a world-class ex­pert.
This is false.
What does the word “dedicated” mean in the phrase “dedicated” prac­tice?
It means ap­ply­ing fo­cused, de­lib­er­ate thought to it.
It means re­ﬂect­ing on your own per­for­mance.
It means seek­ing help from mas­ters in the ﬁeld.
Above all, it means achiev­ing mas­tery is not easy.
I aim to mas­ter the skill of writ­ing.
In my free time this week, I’ve been work­ing on my de­lib­er­ate prac­tice of writ­ing.
In do­ing so, I’ve come to some con­clu­sions.
If you’d like to join me in pur­su­ing mas­tery of the writ­ten word, here’s what I think you should do.
<h2>Proof it Yourself</h2>
Two-time Pulitzer prize-win­ner David McCullough says “Writing is think­ing. To write well is to think clearly. That’s why it’s so hard.”
Because the act of writ­ing is also the act of think­ing, the process of re­vis­ing text clar­i­ﬁes thought.
I per­son­ally ﬁnd that my ar­gu­ment when I ﬁrst touch my key­board usu­ally stands in stark con­trast to when I hit “publish.”
Heavy-handed re­vi­sion tools like ChatGPT ac­tively dis­rupt this great ben­e­ﬁt of the re­vi­sion process.
Sure, they can rewrite tone to be more at­trac­tive on­line, but they also rob you of the op­por­tu­nity to de­velop your con­cept.
That’s why I turn every­thing else off and only use Harper: be­cause it gets out of the way of what I am try­ing to say.
You can’t re­ﬂect on what you’ve writ­ten if you are not the one re­ﬂect­ing.
<h2>Read The Work of Great Writers</h2>
When I sit down to write af­ter spend­ing time on­line, I feel de­ﬂated.
The com­pe­ti­tion of so­cial me­dia and the churn of the news cy­cle both lead to poor prose.
When I sit to write af­ter read­ing Bonnie Garmus or Cal Newport, I feel in­vig­o­rated.
I can imag­ine a shape for the words on the page which pre­cisely cap­tures the ideas I’m try­ing to com­mu­ni­cate.
Read­ing great lit­er­a­ture gives you an in­tu­ition for what your own work should look like.
<h2>Think of the Hook First</h2>
In rap­per cir­cles, it’s a com­mon point of de­bate whether to think of the verse ﬁrst or the hook.
One one hand, the verse is the sub­stance of the song.
It con­tains the mes­sage, the de­tail, and the per­sonal mean­ing.
Mu­sic de­rives much of its com­plex­ity from the verse.
On the other hand, the hook is what gets peo­ple to lis­ten.
It is what makes them stop ﬂick­ing through Spotify and fall into the beat.
If you’re writ­ing for an au­di­ence, you have a lot of com­pe­ti­tion for their at­ten­tion.
Spend more time on the in­tro­duc­tion than any­thing else.
It should cap­ture your read­ers, de­light their imag­i­na­tions, and put them in your shoes.
<h2>Don’t Get Attached</h2>
I spent a long time on a post sim­i­lar to this one.
I was quite proud of it, for I had spent hours adding lay­ers of de­tail and quite a few case stud­ies from my own work.
Alas, Gutenberg de­cided it was not meant to be and chucked it into obliv­ion.
Although I was ini­tially crest­fallen from the loss, I now be­lieve the sec­ond round ended up even bet­ter.
To truly re­vise your work, you’ll in­evitably have to delete parts of it.
Get com­fort­able with that.

Spend more time on the introduction than anything else.

Spend more time on the in­tro­duc­tion than any­thing else.

Always Think of the Hook First

<h1>A Case for Procrastination</h1>
<img src="/images/model_t.jpg" alt="A linup of Model T Fords">
The most valu­able, unique as­pect of soft­ware de­vel­op­ment is the speed at which we can it­er­ate.
Soft­ware pro­jects that don’t it­er­ate quickly and fre­quently usu­ally stag­nate and fail, while pro­jects that work with user feed­back on an al­most real-time ba­sis are the most suc­cess­ful.
I’ve no­ticed the dif­fer­ence per­son­ally, with my work at <a href="https://archytasinc.com/">Archytas Automation</a>.
Most re­cently, I’ve read The Lean Startup, Zen and the Art of Motorcycle Maintenance and The Pragmatic Programmer.
While each uses their own ter­mi­nol­ogy, both go into depth on the depth on the topic of fast it­er­a­tion cy­cles.
<h2>Lean Manufacturing and Lean Thinking</h2>
Lean man­u­fac­tur­ing, as ex­plained in The Lean Startup is a pro­duc­tion method­ol­ogy fo­cused on avoid­ing waste.
The book’s pri­mary ex­am­ple is the Toyota Production System.
In the mid 1930s, the world’s largest car man­u­fac­turer was Ford.
Ford’s fac­to­ries pro­duced thou­sands of unique parts, which to­gether could form a car.
They pro­duced these parts in bulk, and each dis­tinct part had an en­tire ma­chine ded­i­cated to pro­duc­ing it.
There was a ma­chine that made springs, a ma­chine that made nuts, and a ma­chine that made bolts.
No ma­chine could make any part other than the one it was de­signed for.
This was great: it meant that cars would be cheaper than ever, and more peo­ple could ex­pe­ri­ence car own­er­ship.
Around this time, Toyota en­tered the au­to­mo­tive in­dus­try.
How­ever, they did not have the time, nor the money to de­sign and build the same kind of hy­per-spe­ciﬁc man­u­fac­tur­ing ma­chines that Ford used.
In­stead, they chose to pur­chase com­par­a­tively few hy­per-gen­er­al­ized ma­chines.
Their strat­egy was to build one car at time, and sell it as soon as pos­si­ble (ideally the mo­ment it rolled off of the fac­tory ﬂoor).
This way, if there is an is­sue with the ve­hi­cle, the de­sign can be mod­i­ﬁed be­fore too many faulty cars are as­sem­bled.
The Toyota Production System em­pha­sized ﬂex­i­bil­ity over ef­ﬁ­ciency.
By stay­ing ﬂex­i­ble, Toyota gave it­self the abil­ity to op­ti­mize all as­pects of the busi­ness in the mid­dle of a pro­duc­tion run.
On one hand, the Ford process looked like this:
<ul>
<li>Get ma­te­ri­als for one hun­dred cars.</li>
<li>Fabricate over a thou­sand dis­tinct parts re­quired for each car (likely more than a hun­dred thou­sand to­tal parts).</li>
<li>Assemble one hun­dred cars&nbsp;.</li>
<li>Sell one hun­dred cars.</li>
<li>Receive feed­back on ve­hi­cle and pro­duc­tion process.</li>
<li>Perform all pos­si­ble changes to the ve­hi­cle’s de­sign and pro­duc­tion process (which would be very lit­tle).</li>
</ul>
With this many steps, each tak­ing place over a com­par­a­tively long time, the it­er­a­tion cy­cles are few and far be­tween.
On the other hand, the Toyota Production System looked like this:
<ul>
<li>Get ma­te­ri­als for one car</li>
<li>Fabricate the rel­a­tively few dis­tinct parts re­quired for the car</li>
<li>If there is an is­sue with the pro­duc­tion process (a ma­chine breaks, some­one gets hurt, etc.).
Stop the whole process and ﬁx the is­sue, so it will not af­fect fu­ture cars.</li>
<li>Assemble one car.</li>
<li>Sell one car.</li>
<li>Receive feed­back on ve­hi­cle and pro­duc­tion process.</li>
<li>Perform all pos­si­ble changes to the ve­hi­cle’s de­sign and pro­duc­tion process (which could be quite a lot, given the ﬂex­i­bil­ity of both).</li>
</ul>
Counterintuitively, per­form­ing each step with a batch size of one ac­tu­ally ended up be­ing more ef­ﬁ­cient.
Even though Ford ex­pe­ri­enced a higher level of ef­ﬁ­cient within each batch, their process led to many more wasted parts be­ing man­u­fac­tured,
as well as a lack of com­mu­ni­ca­tion be­tween steps, which dra­mat­i­cally in­creased the amount of wasted ef­fort.
Ad­di­tion­ally, be­cause the Toyota Production System al­lowed com­par­a­tively rapid it­er­a­tion, Toyota ve­hi­cles were sim­ply bet­ter: more durable, and more use­ful to their cus­tomers.
<h3>Lean Thinking In Software</h3>
In soft­ware de­vel­op­ment, it can be tempt­ing to go the Ford route:
cre­ate a de­tailed plan of all the fea­tures you wish to add to your ser­vice,
then, de­velop the fea­tures, and de­liver them all at once.
Only then do you ac­cept feed­back and eval­u­ate the use­ful­ness of each fea­ture.
In The Lean Startup how­ever, Eric Ries sug­gests an al­ter­na­tive method­ol­ogy, in­spired by the Toyota Production System.
Before de­cid­ing on which fea­tures to in­clude in your ser­vice in an all-at-once, shot-in-the-dark man­ner, per­form ex­per­i­ments.
Cre­ate an ab­solutely min­i­mal pro­to­type of the fea­ture, give to a cus­tomer, and ob­serve how they use it.
It is pos­si­ble they ﬁnd the fea­ture un­help­ful, or they use it in a way you did­n’t ex­pect.
By run­ning the ex­per­i­ment early on, there are far fewer un­help­ful fea­tures in­tro­duced, and the cus­tomer gets a prod­uct more closely tied to their needs.
Further, it is pos­si­ble that your un­der­stand­ing of the prob­lem do­main is mis­in­formed.
Plan­ning out the en­tire prod­uct re­lease months in ad­vance is prob­lem­atic when the re­quire­ments of the pro­ject change (and they will, of­ten).
<h2>Why Interpreted Languages Can Be So Productive</h2>
Interpreted pro­gram­ming lan­guages are al­most laugh­ably per­va­sive.
Of the top ten most pop­u­lar pro­gram­ming lan­guages on the 2023 StackOverﬂow Developer sur­vey, six were in­ter­preted.
That count does not in­clude TypeScript, which can be used in a semi-in­ter­preted man­ner.
In­ter­preted lan­guage pop­u­lar­ity is of­ten chalked up to their ease-of-use, ab­strac­tion, and sim­ple, English-like syn­tax.
How­ever, I be­lieve there is an ad­di­tional rea­son: they al­low one to it­er­ate much, much faster.
<h2>Micro-iterations</h2>
Iterations can hap­pen on any timescale.
Micro-iterations oc­cur hap­pen over the short­est time scale.
These are small, in­cre­men­tal changes that oc­cur (usually) when de­bug­ging or op­ti­miz­ing code.
It is the amount of time (and by ex­ten­sion, men­tal over­head) that re­sults from a change.
The longer it takes for tests to com­pile and run, the longer it takes to de­bug.
I be­lieve you can model it like so:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mrow><mtext>time to de­bug</mtext><mo>=</mo><mo stretchy="false">(</mo><mtext>time to test</mtext><msup><mo stretchy="false">)</mo><mn>2</mn></msup><mo>∗</mo><mtext>text edit­ing</mtext></mrow><annotation encoding="application/x-tex">\text{time to de­bug} = (\text{time to test})^2 * \text{text edit­ing}</annotation></semantics></math>time to de­bug=(time to test)2∗text edit­ing
<blockquote>
This is not an ex­act, rep­re­sen­ta­tive equa­tion, merely an ab­strac­tion to il­lus­trate my point, based on per­sonal ex­pe­ri­ence.
</blockquote>
In other words, the to­tal de­bug­ging time in­creases su­per-lin­early as the time it takes to test a change to the pro­gram in­creases.
No­tice how, as the <code>time to test</code> in­creases, the ac­tual amount of time <code>text editing</code> falls to a neg­li­gi­ble ra­tio of the to­tal.
I be­lieve this comes from the fact that as com­pi­la­tion time in­creases, the amount of in­for­ma­tion gleaned per mi­cro-it­er­a­tion tends to de­crease.
<h3>JIT Compilation and Hot Reload</h3>
This is where we get to the ti­tle of the ar­ti­cle.
The con­cepts of lean think­ing ex­tend into com­piler tech­nol­ogy.
The Toyota Production System in­cludes the con­cept of “Just-in-time”, mean­ing,
“to only pro­duce ex­actly what is needed for the prod­uct, ex­actly when in the process it is re­quired.”
Avoid plan­ning re­source re­quire­ments ahead of time and build sys­tems that only pro­duce what is ac­tu­ally needed.
While the mean­ing of “Just-in-time” is dif­fer­ent when we re­fer to com­pil­ers, the line of think­ing is ul­ti­mately the same.
In­stead of wast­ing valu­able, hu­man-scale time on com­pi­la­tion and op­ti­miza­tion of ir­rel­e­vant code, just com­pile the code you need, when you need it.
This dras­ti­cally re­duces the amount of time to test, and ul­ti­mately, the time to de­bug.
Further, tech­nolo­gies like React and Flutter’s Hot Reload make it pos­si­ble to com­plete these mi­cro-it­er­a­tions with­out hav­ing to restart your pro­gram.
I be­lieve this is partly why in­ter­preted lan­guages are so be­gin­ner-friendly (other than the high level of ab­strac­tion they typ­i­cally pro­vide).
New­com­ers to pro­gram­ming spend most of their time on syn­tac­tic is­sues and sim­ple run­time er­rors.
By mak­ing mi­cro-it­er­a­tions hap­pen as fast as pos­si­ble, you make these is­sues less an­noy­ing to deal with.
<h3>Procrastination</h3>
If you are in uni­ver­sity (like I cur­rently am), or any other level of ed­u­ca­tion, it can ac­tu­ally be ben­e­ﬁ­cial to hold off on do­ing your home­work.
It is not un­com­mon (at least in my ex­pe­ri­ence) for the pro­ject or pa­per re­quire­ments to change at the last minute.
Some of your peers may choose to com­plete the pro­ject or pa­per as soon as pos­si­ble.
If this is the case, you may ben­e­ﬁt from their ex­pe­ri­ence.
If a cer­tain chain of logic or analy­sis is con­fus­ing or mis­lead­ing, they can warn you to avoid los­ing time.
As­sum­ing they are will­ing, they can also pro­vide in­sight­ful feed­back on your work mid-way through your writ­ing or study process.
<h2>Conclusion</h2>
Iteration is in­cred­i­bly im­por­tant to any de­sign and de­vel­op­ment cy­cle, es­pe­cially in soft­ware.
Since I have em­braced it­er­a­tion, I’ve seen a dra­matic im­prove­ment in my pro­duc­tiv­ity and ef­fec­tive­ness.
So I en­cour­age you: if your build process takes 30 min­utes, spend some time on im­prov­ing it.
If you are work­ing on a pro­ject that has­n’t been put in front of a cus­tomer, try show­ing it to a fam­ily mem­ber or non-tech­ni­cal friend.
Ask them for bru­tal hon­esty, and your pro­ject will be much bet­ter off.

Or: why doing things at the last minute actually saves time. I talk about the importance of shockingly fast iteration cycles and lean manufacturing.

Or: why do­ing things at the last minute ac­tu­ally saves time. I talk about the im­por­tance of shock­ingly fast it­er­a­tion cy­cles and lean man­u­fac­tur­ing.

A Case for Procrastination

the_three_steps_to_an_apology

<h1>The Three Steps to an Apology</h1>
My grand­mother is a won­der­ful woman. She never leaves the house with­out a least a lit­tle bit of pur­ple. Maybe a key­chain or a purse. Sometimes, she would­n’t leave the house with­out a lot of pur­ple, head to toe. She also never for­gets a smile and a good at­ti­tude.
She’s a wise woman. With more than 70 years and ﬁve chil­dren un­der her belt, she’s seen some stuff. All that ex­pe­ri­ence comes with a lot of ad­vice. The three steps to an apol­ogy are some of the best bits of ad­vice she’s ever given me.
<h2>Step One: “I am sorry”</h2>
Admit you’ve done some­thing wrong. Recognize your fault and imag­ine what would have hap­pened if you had done the right thing.
<h2>Step Two: “It will not hap­pen again”</h2>
If you’re ac­tu­ally sorry, you’ll want to avoid repli­cat­ing the same mis­take at a later date. Figure out what you need to do to make sure you this is a one-time er­ror.
<h2>Step Three: “What can I do to make it bet­ter?”</h2>
Attempt re­pair. In a fan­tasy world, you could go back in time and stop your­self from do­ing what­ever it is you did in the ﬁrst place. But we don’t live in a fan­tasy world, so you have to ﬁnd a way to make it right, as soon as pos­si­ble.

Elijah Potter

The Three Steps to an Apology

Step One: “I am sorry”

Step Two: “It will not happen again”

Step Three: “What can I do to make it better?”

Other Stuff

ChatGPT for the Moms

Always Think of the Hook First

A Case for Procrastination

Elijah Potter

The Three Steps to an Apology

Step One: “I am sorry”

Step Two: “It will not hap­pen again”

Step Three: “What can I do to make it bet­ter?”

Other Stuff

ChatGPT for the Moms

Always Think of the Hook First

A Case for Procrastination

Step Two: “It will not happen again”

Step Three: “What can I do to make it better?”