articles
- https://levels.io/startups/ - how to take an idea from 0 to 100
- https://levels.io/copywriting/ - dead simple advice for writing good copy
- https://levels.io/hoodmaps/ - a crazy long post documenting how Pieter built an app from the first line of code to being complete
- I want to make an app for prayer that combines the best elements of Duolingo and Readwise. I often tell people I will pray for them and then forget, so I want to build something that solves that. A place I can store the things I want to be praying for, that also reminds me to pray and maybe even has some gamification to encourage me to keep engaging with my prayers.
- I also want to make a quick capture app. What I really want to make is a widget for an android or iPhone, that makes it dead simple to capture quick notes and have a running log of these quick notes. I haven’t found a satisfying solution for this yet.
- I’ve also considered writing a weekly email newsletter that either has a paid subscription option or a donate option. It would have to be something that provides value… I was thinking either “hacks” for the average office user to use their computer better, or a weekly interview with someone who works at NASA, highlighting the person and their work.
- Make sure Tiny Theme is installed on the Plug-ins page
- create a custom theme (or edit your existing custom theme if you already have one)
- add the following page to your theme: layouts/partials/microhook-post-list.html
- in that page, add the code below:
- save the template
- ChatGPT, from Open AI: https://chatgpt.com/
- Gemini, from Google: https://gemini.google.com/
- Claude, from Anthropic: https://claude.ai/
- Read to get ideas.
- Books
- Articles
- Give yourself plenty of time to write.
- Make an outline to start.
- Shoot for 10ish bullets. Any bigger and it is hard to see the flow of the argument.
- Write a bad draft - remember producing and editing are different activities.
- Produce, produce, produce.
- Write more than you think you need, then chop it down.
- Edit it.
- Rewrite every sentence.
- Reorder until it makes sense.
- Reread the whole thing.
- Refine, refine, refine.
- Create a new outline - Try reconstructing your argument from memory. What you remember is the good stuff. The rest might be crap. Ponder that.
- Cut and paste from your old outline into the new one.
- Make sure you have hyperlinks in the text for citations.
- Case Roles
- Admin (CRUD, only visible to case owner)
- Contributor (CRU, D data they created. Can remove items from diagram)
- Report Editor (R, U report section)
- View Only (R)
Indie Hacking
I have a tendency to be consumed by a niche interest or hobby every now and then. In the past it’s been disc golf, counter strike, yo-yoing, hot sauces, coffee, apologetics, and even card magic. Now I’m introducing the latest interest that my free-time has fallen victim to: indie hacking.
What is Indie Hacking?
Despite having “hacking” in the name, indie hacking is not nearly as nefarious as it seems. It does not involve late night attempts to crack the access code to a terminal while 80s synth wave music surges in the background.
Indie hacking is building software products without a large team and without investments from venture capitalists. Many indie hackers set up their businesses as “lifestyle businesses”, which means that they optimize for time freedom instead of financial growth. So instead of hiring a bigger team to grow the business to infinity and beyond, an indie hacker might set up process automations to make their business run on autopilot so that they can have more time in their day.
My Introduction to Indie Hacking
I started down this rabbit hole after listening to Lex Fridman’s podcast with guest Pieter Levels. Pieter is notorious in the indie hacker community, and has set up several lifestyle businesses for himself, such as nomads.com. After being inspired by his journey, I took a look at his blog and a couple of his posts gave me more to look into:
Looking at these posts then led me to Show Hacker News, Indie Hackers, and Product Hunt. Show Hacker News is a great place to see what other people are building and to see how the “hacker community” responds. Indie Hackers has all sorts of articles and resources with info on getting started. They also have a podcast I just stumbled on today! I had never heard of Product Hunt before, but it’s a place where each day new apps get launched and then voted on. The most popular apps rise to the top, so for the early-adopter community it is a way to see what hot new apps are available, and for makers it is a great way to get visibility and users for a new product.
What Indie Hacking Means To Me
I’ve been inspired by all the stories I’ve read and the products I’ve seen. My day job is fun and rewarding, but it has become removed from coding. I miss the tight feedback loop of having a small feature in my head to build and then bringing it to life. To reconcile that, I’m moonlighting as an indie hacker. I have no grand monetization scheme, no clearly laid out plan, and little free time as a new dad working a full-time job. But I’m building nonetheless. My latest creation is fedmeetup.com, and I just pushed some new updates to it over the last week.
I’m still a bit embarrassed by how wonky the interface looks (need to work on my design skills) but I’m trying to embrace the indie hacker mantra of “ship early, ship often”. Fed Meetup solves a problem (Where should I host a federal in-person event to maximize savings of taxpayer dollars?) in its current form, so I’ve released it into the wild and will build it alongside those using it. I know of at least a couple of people at NASA who have started using it and I plan to broadcast it more widely through NASA. Once it has had success at NASA, I’ll start outreach to other agencies.
On top of Fed Meetup, I have other ideas that I’m itching to build:
This is just the beginning of my ideas, so I’m going to create an /ideas page on this blog to store all of them. I want to share these publicly partly for accountability and partly because I think they need to be built, so I welcome others to build them too! If you have any interesting ideas you think we could work on together, I would love to hear them.
The Piece I’m Missing
The main way I differ from other indie hackers is that I don’t have an intense focus on monetization. I’m more of an indie hobbyist, who may one day metamorphose from hobbyist to hacker. Indie hackers are usually very focused on their Monthly Recurring Revenue (MRR) which is the key measure for a subscription based business. After reviewing my financial situation, my MRR between my blog and Fed Meetup is -$7. I pay $5/mo for blog hosting, and about $1/mo each for my domain names. And none of this is pulling in any money.
For now, I am content with that. I’m enjoying the craft of both writing and building software products. It brings me immense joy to write these blog posts and to build things like Fed Meetup. However, I do dream of a day when the side projects I’ve built over time could support my family financially. I am quite happy supporting my family through my W-2 job, but I am attracted to the romanticized freedom that having my own business(es) would afford. I know it won’t be all sunshine and rainbows, but I think it would fit my personality well.
In my mind, the key to all of this is experimentation. This is not a big announcement of a shift in focus or career for me. Rather, this is me sharing a potential future path that I plan to experiment with. I plan to start small with my hobbyist projects, giving some more thought to how I can monetize them. Actually, I’m quite excited about experimenting with monetization and value. Stories like the Zappos founder, Nick Swinmurn, fuel my imagination. He set up an online shoe store before having any inventory. While he was validating the company’s value proposition (would people buy shoes online without trying them on?), he would receive orders and then go out himself to local shoe stores to buy shoes and ship them out. Finding opportunities for this kind of “Wizard of Oz” testing to validate business viability is exciting and fun to me.
So why am I sharing all of this? Because you can expect to hear more from me about what I’m building. Building in public is about authentically sharing the journey from idea to product. I hope to do just that and I invite you to join me and follow along.
Using Tiny Theme Microhooks to make your homepage display a reverse chronological list of long-form articles, grouped by year
I’ve been feeling like my home page wasn’t what I really wanted people’s first experience with my blog to be. I want people to be able to get a high-level overview of what I write about and what my interests are. I admire other blogs that just have a list of long-form articles, so I decided to update my home page to work similarly.
Check out my new home page at weidok.al

For anyone else using the Micro.blog Tiny Theme that wants to do the same, here is how I did it:
Instructions
Warning: Keep in mind that this is one of the more power microhooks in the Tiny Theme, so it may override other microhooks you have already set up
<div class="home h-feed">
{{ $posts := where .Site.RegularPages "Type" "post" }}
{{ $articles := where $posts "Title" "!=" "" }}
{{ range $articles.GroupByDate "2006" }}
<h2>{{ .Key }}</h2>
<ul class="post-list">
{{ range .Pages }}
<li class="h-entry" style="padding: 0.5em 0;">
<div style="display: flex;">
<div class="post-meta" style="flex-shrink: 0; width: 60px; margin-right: 10px;">
<time class="dt-published" datetime="{{ .Date.Format "2006-01-02T15:04:05Z07:00" }}">
{{ .Date.Format "Jan 02" }}
</time>
</div>
<div style="flex-grow: 1; min-width: 0;">
<a href="{{ .Permalink }}" style="word-wrap: break-word; overflow-wrap: break-word;">{{ .Title }}</a>
</div>
</div>
</li>
{{ end }}
</ul>
{{ end }}
</div>
And voila! Just like that, you’ve updated your homepage to show a list of reverse chronological posts, but only showing long-form articles grouped by the year.
Street Corner
Today I found myself in the downtown area of an old, little rural Ohio town. Surrounded by brick buildings, with a large, antiquated concrete community bank on the opposite corner. I stopped in at a local Chinese takeout place with my family for lunch. We ordered our food, and were told the customary “10 minutes”. While waiting for them to prepare our food, I stepped out onto the corner with my daughter.
It was… unremarkable. Another typical Ohio day in a quaint Ohio town.
But doing unremarkable things with a one year-old can suddenly make them remarkable.
My Meeting Philosophy
26 Pieces Of Advice To My Past Self
A Recommendation for Trying AI
The following is a message I shared with my organization today.
In light of NASA’s push to train up the workforce on AI, I wanted to share a tool that I’ve been using in my day-to-day. This is a simple tool that would be a good introduction for folks who haven’t been using AI much.
Perplexity AI is a conversational AI assistant and search engine that provides citations for sources it is using. You can also specify whether you want it to only search through academic journals, Reddit, or other sources.
I’ve been using this about as much as I’ve been searching for links with Google. I’ve been using it for research, learning new things, troubleshooting other tools I use at work, etc. The cited sources help me to see where the answer is coming from, to judge whether I should trust it or not. And it’s really easy to use. Just type in a question you want an answer to, and it will give you cited responses.
A lot of the other big LLMs are good too, and each have there own strengths and weaknesses. Perplexity would be happy to tell you what they are!
Some others I’ve tried are:
How to Write a Kickass Article
I would like to note that as I write this, I am not following the advice contained within whatsoever.
I want to write better articles. I want to use them to reason and think. I would like to do some research and link to sources, so that my articles have some ground to stand on and they provide real value.
To this end, I’ve been doing some research on writing a good article and I made the cheat sheet below for myself. I don’t plan to follow this dogmatically, but it will help me remember what to focus on in different stages of my writing. The following is primarily a reframing of the essay app’s writing guide, because its advice resonated with me the most of what I found online.
How to Write a Kickass Article
Experimentation Is Where the Fun Is At!
My new shipment from The Goulet Pen Company makes it feel like Christmas!

I ordered their notebook sampler and got a random ink sample set for free.
An Analog Blog Post
The following was transcribed from the pictured journal entry. I used Google Lens and a LOT of editing.
It has been easy to not make time to write recently. “Busyness” is the main culprit, but I’ve also been spending time with its less boisterous sibling, distraction. And so here I find myself, back at the roots of my writing practice. The journal. I’ve missed the empty page. The empty screen is nice too, in my writing software of choice, but I can’t help feeling the weight of the myriad windows/apps/messages vying for my attention. So I’ve returned to my empty page. It welcomes my attention and thought, but does not compete for them. It is an escape in plain sight.
Check the Categorization of Your Domain in Cloudflare Radar to Make Sure Federal Employees Can Visit Your Site
Is this a blog or a node in a botnet?
I finally found out why my blog was blocked on the NASA network! Cloudflare had it categorized as a DGA Domain, so they thought it was an autogenerated domain that was part of an evil botnet 🤦♂️ I’ve submitted a request for Cloudflare to recategorize it under “Personal Blogs” so it doesn’t show up as a security threat any more. I guess my last name does look a little suspect and not quite like a real word someone would use for a domain…
Compound and Leverage
Compound and leverage are powerful forces to move us toward our desired outcomes.
I’ve been thinking about these two forces and how they can be used not only to improve finances, but they also apply to other areas of life.
NASA's First Agile Technical Interchange Meeting
Yesterday was NASA’s very first Agile Technical Interchange Meeting! NASA is becoming agile 🚀🏃♂️💨
I learned how Agile is applied outside of my discipline, web software, to improve how we build hardware and integrated systems, particularly in the systems engineering discipline.
Introducing Fed Meetup
A Day In My Life At NASA
On days like today, I marvel as I reflect all the awesome things I get to do in my role here at the NASA Safety Center.
Today I…
🐛 Hosted a “bug hunt” for the new app we launched last month, having the whole development team try to break the app to catch bugs before they become an issue.
🌒 Spoke with someone from the Human Landing System program about their interest in using a fishbone (Ishikawa) diagram to identify what could cause the lunar lander to tip over during landing. This is a problem that has plagued recent commercial lunar landings, and we are looking to support these use cases in our new app.
🥗 Ate a fantastic salad with my team at the café in the new Research Support Building at NASA Glenn Research Center
🤹♀️ Consulted with a co-worker about how we could use Microsoft Delve to surface Reliability Engineers in the agency with unique skills that could be shared with others in that discipline.
📊 Reviewed the Science Mission Directorate’s system for tracking risks to inform how our team will build an agency-level tool that surfaces elevated risks from the mission directorates.
👬 Demoed our API for mishap data to a group building a Digital Twin of NASA facilities. Mishap data could be layered with information we have on aging infrastructure to build a compelling case for which areas of NASA’s infrastructure are in the most need of attention.
And that all is just the tip of the iceberg! Looking forward to tomorrow!
A Brief Thought On A Recent Bout of Resistance
Gotta get back on the ol' blog! I’ve been working a bit on a draft of an article, but have been having some resistance to finishing it. Do I keep it long and playful like it is now, or cut the fluff and get right to the message?
I’ve been pondering this question, and I think the right answer is to just get the dang thing out into the world. Have fun writing it. The style does not matter. Either way, it will be a hit with some people and a miss with others. And that doesn’t matter anyways. I want to write for me to work through things and hopefully that helps others along the way. But if not, fine!
Just write Jake!
Text Message Triage
Me: “Oh, I need to respond to that later.”
Text Message: cries softly as it floats into the void, never to be seen again
To Be Good, You Must Be Dangerous
“They see they can and must stand up, because they begin to understand how genuinely monstrous they will become, otherwise, feeding on their resentment, transforming it into the most destructive of wishes. To say it again: There is very little difference between the capacity for mayhem and destruction, integrated, and strength of character. This is one of the most difficult lessons of life.”
To be good, you must be dangerous.
Much of my life, I equated dangerous with bad. But I have come to realize that a chief aim of the good ought to be to increase their dangerousness. This is necessary when operating in and around evil.
A capacity for evil is not inherently bad. Your capacity is morally neutral, but it is up to you to wield it appropriately. C.S. Lewis illustrates this well when answering the question of why there is evil at all:
“‘Why did God make a creature of such rotten stuff that it went wrong?’ The better stuff a creature is made of—the cleverer and stronger and freer it is—then the better it will be if it goes right, but also the worse it will be if it goes wrong. A cow cannot be very good or very bad; a dog can be both better and worse; a child better and worse still; an ordinary man, still more so; a man of genius, still more so; a superhuman spirit best—or worst—of all.”
Jesus makes this point too, when telling his disciples that they ought to be wise as serpents. This is potent imagery considering it was a serpent that caused the fall of man.
“Behold, I am sending you out as sheep in the midst of wolves, so be wise as serpents and innocent as doves.”
He implores them to wield the wisdom of the serpent with the innocence of the dove. Why not just tell them to be innocent as doves? Because to be good, you must be dangerous.
This then, is the aim of the good: to be cleverer and stronger and freer. To be dangerous.
My User Story Template
Below is the template I created for writing user stories.
# User Story
As a...
I want...
So that...
# Description
Lorem...
# Acceptance Criteria
- bullet criteria
GIVEN setup
WHEN action
THEN result
I write a lot of user stories for my team, and they need to be clear, to the point, and verifiable. This template was born out of a need for consistency in how user stories were defined and written and aims to give a development team the bare minimum they need to deliver a hot, fresh slice of valuable software. Nothing here is ground-breaking, but it serves as a foundation for defining work when building software.
User Story Statement Section
First, we start with the traditional user story statement.
As a
I want
So that
This forces the author of the story to be clear about who wants what, and most importantly, why they want it.
For the As a
clause, try to be clear about a specific type of person. If your description can conjure up a mental picture of a distinct archetypal user-type, you’re doing it right. Avoid writing simply As a user
at all costs. We’ve all done it, and we should all be ashamed.
In your I want
section, describe one want. If you are tempted to have more than one clause here, you might consider if an additional user story is warranted.
With the So that
clause, focus intently on the unique value this will provide to your archetypal user-type. This is the hardest clause to write, but also the most important to do well. It’s value may be obscure to some, because it does not directly contribute to the “spec” of what needs built. But this is your chance to clearly define the impact of this work to be done. It breathes life into the code to be written, and gives your designer, developer, tester, etc. a clear reason for doing what they’re doing.
Description Section
This is your chance to go into more detail about your user story. What should the user-facing phrasing be? What data are we working with?
I often will take a first pass at this providing as much important context and detail as I can from the product perspective. Sometimes, a developer will go into description after I’ve written it and add a subsection for Technical Details
to go more in depth on any technical nuances to the user story that should be considered during development and testing.
Acceptance Criteria Section
Acceptance criteria gives the team a clear basis to know when they are done with a user story. It is something we can point to and either say “Yes, we accomplished what we wanted to” or “No, this doesn’t do everything we needed”.
I write acceptance criteria one of two ways, and sometimes I use both.
Bullet Syntax
Acceptance criteria can be a simple bullet-list. This is more often the case for smaller user stories, or ones that are more technical. This can be a simple, useful tool to include any non-functional requirements that need to be met to accept the user story.
Gherkin Syntax
When it makes sense, I write acceptance criteria in GIVEN, WHEN, THEN format. This lays out a very clear path for manually testing the user story, and this syntax can be used for behavior driven development. It becomes an executable spec that we can use directly in our automated tests.
Example
Here’s an example of a user story I’ve written recently:
User Story
As a case owner or admin
I want to add users to my case
So that I can collaborate with others
And determine appropriate access levels for CRUD operationsDescription
link to mockups
The scope of this ticket includes setting up roles in the application. See the roles matrix for the case-specific roles in the application.
Add a button in the top right to add case members (see mockups, only visible for case owners and admins).
Owners and admins can add other members. The owner can add Admins, but Admins cannot add other Admins.
After clicking the button, the user selects a person and a role, and then can save them as a member to the case. After saving, the new member should be displayed in the case members table.
The role options will be…
Note that “Owner” is not one of the role options, because the owner is whoever created the case and there will only ever be one owner per case.
Acceptance Criteria
GIVEN I am a
(owner, case admin)
WHEN I add a member as a contributor
THEN the member is displayed in the case members table with the contributor roleGIVEN I am a
(contributor, report editor, view only)
THEN I do not see the button to add a memberGIVEN I am “case admin”
WHEN I am selecting the role for a new member
THEN I can not select “case admin”
While this template helps define the user story, it is important to remember that the user story is a placeholder for conversation. If you write this up and then immediately push it to your team to work on it, you’re missing the beauty of the user story. Bring your draft of the user story before the team and then have a conversation about it. Invite ideas and questions from others on the team. Define and come to a common understanding of the problem to be solved, or the value to be delivered. Then determine how you will bring forth that solution or value.
If you adopt this template or some variation of it, reach out to let me know!