articles
- 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)
- A personal 1:1 recommendation - “Jake! You gotta check out….”
- A link in a post I’m enjoying (falling down a rabbit hole)
- A blogroll on a personal site
- A blog listing site (like those linked above)
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!
Who Am I?
I am the outlaw.
I am the innocent.
I am the sage.
I am the jester.
I am the everyman.
I am the ruler.
I am the caregiver.
I am the explorer.
I am the hero.
I am the artist.
I am the magician.
I am the lover.
I am the slave.
I am the master.
I am the giver of life.
I am the wreaker of havoc.
I am the one who decides.
I am you.
Blogroll
I added a blogroll to my site! I had been thinking about creating this for a while, and the new recommendations feature in Micro.blog gave me the push to finally do it. I added it to my navigation links, but… it’s getting really crowded up there. I may have to do something about that, but I want people to be able to find my blogroll, and putting a link in any of my other pages didn’t seem quite right.
For now, it is just a list of sites, but I’d like to add little one-liner descriptions of why I like each site. I’ve had a lot of fun discovering blogs through the blogrolls of others, and I’m excited to start to share my own recommendations! My list will grow as I discover new blogs. Right now I’ve been finding a lot of interesting blogs by clicking around at https://blogroll.org/ and https://ooh.directory/. These are awesome resources to find independent folks sharing from their own space on the web.
My favorite way to discover sites though is through personal recommendations. The more organic, the better. Here’s my rank order of favorite ways:
If you have some blogs I need to check out or other ways of discovering blogs, I’d love to hear about them!
Remember To Live, An Interactive Haiku
days lived
more to go
remember to live!
Input your own numbers into the haiku above as a reminder to yourself to live!
For the first box, calculate your_age_in_years * 365
For the second box, calculate your_expected_max_age_in_years * 365 - first_box_value
calculator-1.com
Originally I had hoped to make this much more dynamic so that you could input your current age and expected max age and I would handle all the calculating behind the scenes, but alas Javascript doth not jive with Markdown.
Haiku
I’m adding a new category on my site for haiku. Most of these will be quick micro-posts, but others may be longer. I have an idea for an interactive haiku but I’m not positive how that will work since my posts are published in Markdown. It should be a fun mini-project!
To my chagrin, I tend towards rule-following, so most of my haiku will follow the 5-7-5 format. I would like to experiment outside of those lines from time to time.
Here are some haiku I’ve been workshopping in my pocket journal:
whatever you do
must matter so you enjoy
whatever you do
I will be faithful
all of my days are for you
no one else will do
flowers dance in wind
clouds amble along slowly
people collect likes
quite peculiar
is the love of a small child
pure, strong, undeserved
oh you fool! live more!
think often of your deathbed
it is near, not far
look how far I ran
so far to be same old me
right where I began
Tear It All Down
My website looked quite different at its beginning. I thought starting a blog would be a good opportunity to play around with new technology, so I decided to teach myself SvelteKit and build my site with it. It was very exciting: I would build in SvelteKit, write all my posts as standalone markdown files, and deploy on Vercel. As I started building and exploring what other people had done to get inspiration, I came across a concept called the IndieWeb. I felt aligned with the values of this web community, so I wanted to build my site to be part of it. Suddenly, my to-do list was expanding rapidly to include all sorts of IndieWeb specs and principles. Would markdown files be enough to do everything I wanted to do? Perhaps I would need to set up a database using something like Supabase…
The more I added to my to-do list for the site, the more I began to dread working on it. This was supposed to be fun, what happened?
I lost my Why. What I really wanted was to start writing. To have a place to share myself and to figure out how to do that. That was my Why. But I wasn’t clear on that. I thought this site would be a good place to write and be a fun coding project. Mixing those was a mistake for me. I became so consumed with perfecting the design and functionality that I had no time to think about writing.
So what to do? I had this thing that I built, that I actually quite liked, but it was taking me further from my Why rather than toward it.
I decided to tear it all down.
I threw everything away and started from a blank slate. How could I just write? How could I stay connected to my Why? A blogging platform, duh! Other people have already solved the problem of creating a website whose primary purpose is publishing writing. In fact, Manton over at Micro.blog solved that problem and built his solution on the IndieWeb principles I admire, so that was the clear choice for me. I took everything I had written and migrated it over to Micro.blog, abandoning my SvelteKit project.
After the migration, everything felt better. I had space to write, space to bring forth my Why. I still couldn’t keep myself from customizing themes and plugins to make the site my own, but a little bit of play is okay as long as it leaves my Why undisturbed.
Why had this not been obvious in the beginning? Well for one, I didn’t even know about Micro.blog or the IndieWeb when I started out. But more importantly, my thinking had been clouded by an unclear Why and a fear of judgment, which I’ve come to realize are connected. My fear was something like, “This is supposed to be a web software guy and he didn’t build his own site from scratch? He must not really know his stuff.”
That’s a silly fear. Who cares? Have you seen all the intelligent people working in the web space that host their sites on a platform? They’re everywhere! And yet, I could not come to that realization until I was really clear on my Why.
I share all of this to implore you to evaluate your Why. Do you have the right Why? Are you clear on it? Is what you’re doing moving you in the right direction? If not, it’s very possible that you can make minor course corrections to get you back on track. You should try that first. But if you’ve gotten far away from your Why, don’t be afraid to tear it all down. It’s okay to start at zero. The sunk cost has already sunk, so don’t drown yourself trying to save it.
Tearing it all down is not the fastest way to do a thing, but it may be the way to do the right thing.
Here are some screenshots of what the site looked like before. I had a v1 for my homepage, which was ripped off from this YouTube video: Build & Deploy a Modern Web Portfolio w. SvelteKit & TailwindCSS (youtube.com). That felt fake and not like my own, so I started to simplify it into a v2 before deciding to tear it all down.
v1 homepage
v2 homepage
Articles page
Articles page - light mode
Article page
Connect page
Tags/Categories Page
A Piece of My Self
A blog post is not just a piece of writing to me. It is a piece of my self, and these pieces track the process of my becoming. Sometimes I forget and I get lost, so these pieces and connections help to bring me back to who I am and who I aspired to be.
- Winnie Lim, in P&B: Winnie Lim
I appreciate this reframing of a blog post as a “piece of my self”. As I set out in the early stages of my blog, this captures quite well what I aspire for it to be. Each post is one tiny piece of me, a snapshot in time of one aspect of my self I thought worth sharing. Brought together as a whole, they tell a scattered story of my wanderings.
Some posts will be technical, some funny, some vulnerable, and some excited, because these are all pieces of my self. I look forward to looking back on years-old posts, and reminiscing where I was on my path at a given time. I already enjoy doing this with personal journal entries, but I have a sense that there will be a unique quality to reflecting on the progression of my blog.
I am also eager for serendipitous moments when someone encounters one of these pieces of my self, and is so compelled by it that they take time to discuss it with me. Positive or negative, if someone is engaging with one of these pieces of my self then it must have struck a chord, and I think that is a decent signal that I am approximating Truth, which is one of my ultimate aims of this blog. To be truth-seeking in my self and truth-seeking in my interests.
I already felt this a bit with my recent post on My Obsidian Daily Note Template. I was astounded by how quickly people were adopting parts of it or all of it. As I published it I thought, “Is this too ‘in the weeds’? Did I waste my time going into all this detail?”. But there were people out there, quite a few, looking for someone to guide them through these particular weeds. It is a wonderful feeling to create a point of connection. Something you and another can both behold and say, “This resonates”.
So this, too, is one piece among others. If it resonates, I would love to hear from you.
Recent Microblogs
Early morning indie hacking on the back deck with coffee brewing… Bliss ☕💻
I present to you… “Jake Jobs”. Google AI Studio is fun 😂
