Forem: Nathan Kallman

Swagger Codegen and Multiple Tags

Nathan Kallman — Mon, 09 Feb 2026 16:06:59 +0000

Today ChatGPT lied to me, so I’m setting the record straight. This is my question: “If an endpoint in an OpenAPI spec has multiple tags, what will Swagger Codegen do?”. Because Swagger Codegen organized the generated code into api/tag_name_api files. So what if there’s multiple tags? Does it take the first tag? The last tag? Or does it generate a file for each tag and give it the same behavior? ChatGPT claimed it takes only the first tag. I’ve already revealed that’s false, so I guess I don’t have any dramatic reveal, so let me just spout the details for you.

Methodology

I used Swagger Codegen V3 Online Generator: https://swagger.io/docs/open-source-tools/swagger-codegen/codegen-v3/online-generators/

I POST ‘ed to https://generator3.swagger.io/api/generate on 2/9/2026 with a payload looking like this:

  "specURL" : "my.code/openapi/v3/swagger.yaml",
  "lang" : "ruby",
  "options" : {
    "gemName": "liar-liar-pants-on-fire",
    "gemRequiredRubyVersion": ">= 3.1.4",
    "gemSummary": "Liar Liar Pants on FIRE", 
    "gemDescription": "",
    "gemAuthor": "Me"
  },
  "type" : "CLIENT",
  "codegenVersion" : "V3"
}

The swagger had tag sections that looked like this (two endpoints, each with one differing tag and one common tag)

get:
  summary: Get thingy
  operationId: getThingy
  tags:
    - Better Grouping
    - Thingies
get:
  summary: Get whatchamacallit
  operationId: getWhatchamacallit
  tags:
    - Better Grouping
    - Whatchamacallits

Results

The generated code had three files api/better_grouping_api.rb, api/thingies_api.rb, and api/whatchamacallits_api.rb.

And wouldn’t you know it, better_grouping_api had the code to call both endpoints and the thingies_api and whatchamacallits_api had the duplicated code for their correspondingly tagged endpoint.

So there you go, if you have OpenAPI spec with multiple tags, it looks like Swagger Codegen v3 will yield the behavior under each of the tag_api files it generates for each tag.

Has AI Taken My Job Yet?

Nathan Kallman — Tue, 19 Sep 2023 20:30:01 +0000

AI will not change the world (the way you think it will). Exactly as the Internet did not change the world (the way early adopters thought it would).

Of course, our daily lives have drastically shifted in the 30 years since home internet connected us. And of course, our lives 30 years from now will look even more different after consumer AI weasels its way into everything we touch.

But if you don't remember the late 1900s, the internet advent came with a different optimism. The quintessential phrase of the day, "The Information Super Highway!!", encapsulates all the hopes and expectations of the technology. We still echo those hopes when we wax on about the sheer knowledge available a tap away. With all those learnings we'll all make better decisions, self-educate throughout our lives, and society will grow greener each day. Now I hear the emptiness in our echoes. This is not The Internet I was promised. And AI will not become what the sirens sing of today.

It all started at Babel

You may already know, or you may be today's lucky 10,000, about the Library of Babel. Each time it makes a new round on social media there are a dozen reposts about how mind-blowing it is that everything ever written or that ever will be written already exists in the library.

Nearly every introduction to the Library of Babel leaves off at this unspoken existentialism. Implying that it could somehow change our lives if only we looked in the library for all the knowledge we are missing. They have not spent enough time in the library if they believe this, and it shows.

The creator of the library said this after building a search function able to take us directly to the book and page for a given passage of text:

Interestingly, this leaves the frustration of using the library unaltered. One can find only text one has already written, and any attempt to find it in among other meaningful prose is certain to fail. The tantalizing promise of the universal library is the potential to discover what hasnt been written, or what once was written and now is lost. But there is still no way for us to find what we dont know how to look for. Unless, of course, youre brave enough to browse...

The reason the Library of Babel has not changed your life is because any useful knowledge is buried in a hopeless mire of gibberish.

Take this thought experiment: we are literally trapped in the Library of Babel, our world only consisting of bookshelf beside bookshelf with no escape, having never seen the sky outside. One day we miraculously find a page with the words "The sky outside is orange". Astounding scientific discovery?! No, the statement "The sky outside is blue" must also exist within a different book, elsewhere in the library. The library contains all statements, both true and false. This is the nature of Universal Libraries. With no way to verify this statement, we can do nothing with the knowledge the library tried to bestow on us.

Universal Libraries

Such is the fate of all Universal Libraries. By containing information both useful and useless, only the librarians already knowing which books are useful can find a good book. By containing statements both true and false only the researchers already knowing what's true can find veracity. By containing stories both beautiful and ugly, only already discerning eyes can find the aesthetic.

Authorship bestows value to the works. Books, images, and songs are not worthwhile because they exist, but are valuable because they were authored. Out of all the sounds, of all the colors, of all the letters, this particular group was chosen and placed together; or more importantly, all the other combinations were removed, bringing focus to the worthwhile.

The Internet

It strikes me that the Internet is a Universal Library. Perhaps the most universal we've built to date. (of course, containing the entire Library of Babel makes it more universal than that library on its own). Like Bo Burnham sang in Welcome to the Internet from his 2021 special, Bo Burnham: Inside:

Obama sent the immigrants to vaccinate your kids!

Wait. No, that isn't the quote I was looking for. This library is too big. Here:

Could I interest you in everything, all of the time? A little bit of everything, all of the time? [...] Anything and everything, all of the time

It certainly feels as though everything is here. This article is here. The Library of Babel is here. Infinite scrolling on every page.

Let me propose a test for you though; for each thing you see, ask yourself three questions, and be honest with how much of the content you consume satisfies all three:

Is this mostly new to me?
Is this useful to me?
Is this true? Or is it misleading?

Be honest. Does 80% of the Internet satisfy just three questions? Even 20%? I was promised an "Information Super Highway" and instead I wade through an information swamp. The reins to unimaginable knowledge now bind me to a worthless merry-go-round of diversion.

Google boasts millions of results for every search, and yet I find the same shallow parroted lines behind every link. Worse than the Library of Babel, which mindlessly serves me gibberish, the Algorithms of the Internet have been crafted to serve me intentionally manipulative information: attempts to sway my votes and attempts to spend my dollars, mostly attempts at my dollars; never useful for me unless it's more useful to them.

And when you last searched, was there a primary source listed on the first page? I do not mean Wikipedia. I do not mean an article about news coverage of a new study. I mean the actual source of information. I find ten of the same rehashed summaries, probably written by a computer, and if I'm lucky one of them has linked to their source (which is paywalled and out of date).

We fell for the siren song of a Universal Library. Now I hear a remix crescendoing.

Generative AI

So far, Artificial Intelligence (AI) manufactures uncanny mimicries of human intelligence. AI, like humans, mostly recombines information into non-novel restatements of the same. Occasionally an AI, like a human, forms a novel combination: emergent work from previous learnings. Of those emergent works, some portion are truthful (that is, the predictions drawn from them will match reality) and some portion are false.

Unlike a human, an AI has no means to assess its novel works. Like the librarians of Babel, the AI is trapped within its Universal Library: the Internet. It cannot know if the sky is blue or orange outside of words and images transmitted to it via the Internet.

When training human minds, our teachers take great care to bring new, useful, truthful information into the developing intelligence. Have we taken the same care when training artificial minds? Or do we blindly feast them on a Universal Library?

When done blindly, the AI becomes a larger Universal Library than the content it consumed. As it becomes more universal, it paradoxically becomes less useful. Interactions devolve into hallucinations and false citations; how could the AI know any better? That is all it experienced on the Internet. Employing the AI only gives legs to the Universal Library of the Internet. It is no more true than before. It is no more useful than before. The difference is that now it enacts its disheveled will without the filter of external curation.

What will change?

We finally come to the biggest headline (that I see) from Generative AI advancements: "Programmers around the world, out of a job". Except, that headline has been running for 30 years. And it does not sound any different than the existential dread in the shallow sharing of those discovering the Library of Babel. They both have it wrong.

As I said, programmers have been "replaced by technology" since before I was born. How did I make a career doing something that shouldn't exist? How do I know I'll still exist despite AI "taking my job"?

The answer is simple. Each time a new technology enters meant to replace the skills of a professional, a new set of skilled professionals arises to interact with that technology. We saw it again this time around, before the ink on the "out of a job" headline dried, a new job title arose: Prompt Engineer.

The skills we can see change; less documentation on syntax, perhaps a touch more psychology. But the jobs continue. And why these classes of "technical" people always arise is because the skills we can't see stay the same. A craving for learning things, tenacity when facing challenging puzzles, creatively bringing different solutions to the same situation.

So, until AI does everyone's jobs, there will be jobs titled something engineer to take care of the rest. I'll see you all there.

Double-entry Bookkeeping for Programmers

Nathan Kallman — Mon, 30 May 2022 11:12:24 +0000

Cover photo by Ibrahim Boran on Unsplash

This is the article I wished existed when I needed to support accounting functions. Double-entry Bookkeeping may seem esoteric and unnecessarily complicated, but actually describes a simple framework for maintaining a correctible and auditable record of state changes.

This is not a practical guide on how to actually do modern accounting. It only looks at some mechanics of Accounting, not practical operating concerns.

Defining words

Credits and Debits. Forget anything you think you know about what these words "mean". One of them isn't "positive" or "negative". Neither are "good" or "bad". They may as well be called left and right. They don't "mean" anything. They are only mirrors of one another. They only have words assigned to know their chirality.

Next up, Accounts. A confusing word from thousands of years of accounting. But I'll forgive them, naming things is hard. If a programmer were inventing accounting it would probably be called a type or category or collection. An Account is just a bucket giving a name to some money (distinguishing it from the other money being accounted for... oh wait, maybe that's why they're called accounts... who knew).

Accounts come in two flavors: Credit-based and Debit-based. Describing which way all the Credits and Debits against the account should be added up. Credit-based Accounts subtract the sum of Debits from the sum of Credits ( Credits - Debits). And following chirality, Debit-based Accounts subtract the sum of Credits from the sum of Debits ( Debits - Credits). Note in accounting practice accountants often subdivide these two flavors into ~5 main accounts which are put into the accounting equation. By convention, the asset-ish accounts are Debit-based and liability-ish accounts are Credit-based. Again, this article is not meant to delve into accounting practice; knowing the fundamental mechanics suffices for today.

To summarize:

Credit: The opposite of a Debit
Debit: The opposite of a Credit
Account: A label for certain Credits & Debits to be summarized together
Credit-based Account: Account whose Total = Credits - Debits
Debit-based Account: Account whose Total = Debits - Credits

Hopefully Double-entry Bookkeeping just became slightly more approachable. Slightly. Three words in five concepts form our core. But now let's actually use these things...

Double-entry Bookkeeping is NOT a Table

Crack open any accounting book or introductory blog post. Not long into the text there will be tables looking like this:

Account	Credit	Debit
Cash	42
Loan		42

This is how double-entry bookkeeping gets its name; it takes two entries to record a single action. It may also be the most unintuitive way to present financial activity.

A layman's description would be that $42 was taken from Cash and given to (or paid to) the Loan. To and From... hmmm, let's rewrite that table:

From Account	To Account	Amount
Cash	Loan	42

This format hints at a new way to break our thinking free from our table-based accounting mindset. What if we thought of our record as a graph?

Double-entry Bookkeeping is a Graph

Make each account a node and each credit/debit pair a single arrow (aka directed edge; credits/debits start/end the "arrow" respectively) with the amount (aka weight) and each account (aka node) involved. Here's what that weighted directed graph would look like:

Now you may have heard the rule of Double-entry Bookkeeping: "Every Credit must have a Debit and every Debit must have a Credit". Obviously, an arrow always has a start and an end (or to and from). So the graphical form of Double-entry Bookkeeping makes following the rules inescapable.

But how do we represent external movement of money? We do get paid for our work after all. Not only that, but I made five whole dollars from this blog. For a moment, let us relax that rule and let money come from nothing into our Cash account.

This works, but there is some unhelpful lack of information here. If we back this graph into a table, we might label the "from" account of those two new actions as null.

From Account	To Account	Amount
Cash	Loan	42
null	Cash	100
null	Cash	1000

We don't have to label it as null though. In graph theory, we could label null as anything and the graph would be equivalent. Choosing something appropriately vague, we can draw an equivalent graph of our situation looking like this:

While these accounts are not particularly helpful (why did I get $1000? why the $100?) we have answered the question of how to represent money moving to and from external sources. Simply make up a new node (aka account)! Instead of one, vaguely named, "Outside" account, make one for each source we need to account for. And to round out our example, buy some food and set aside some money for later:

Representing external parties as their own nodes brings some interesting qualities: Adding up our Employer and Side Hustle accounts results in total income while looking at them separately tells me which pays better. Same for expenses (McTaco King's looking a little over-visited); but also internal money maneuvering. Keeping an emergency fund, for example, can be viewed as a "loan" that is "repaid" when the fund is used and rebuilt; graphically there is no difference between a loan from an "internal" account and an "external" account (besides interest; I gave myself quite the deal).

But Keep the Double-entry Book in a Table Anyway

While it is useful to think about our accounting as a graph it will not be useful to see our accounting as a graph after a year when we have 24 edges between Employer and Cash and 200 between Cash and McTaco King (don't judge me).

How about we backtrack our graph into tabular representations and see what we get out of it:

From Account	To Account	Amount
Cash	Loan	42
Employer	Cash	1000
Side Hustle	Cash	100
Cash	McTacoKing	12
Cash	Savings	50

Being a table, shoving this data into SQL (or CSV or Excel) becomes trivial. But this format takes a little trickery to group and add up the account values correctly. If we return to the "classic" table form:

Account	Credit	Debit
Cash	42
Loan		42
Employer	1000
Cash		1000
Side Hustle	100
Cash		100
Cash	12
McTaco King		12
Cash	50
Savings		50

We can easily total this table's accounts using either sum(Credit) - sum(Debit) or sum(Debit) - sum(Credit) and grouping by the account. But we have traded the easier reading of what any one action has done by needing two lines instead of one for this easier aggregation.

Rabbit hole: if you want some psuedo-SQL on how this second table could be made from the first, it would probably look like this:

SELECT
   FromAccount AS Account,
   Amount AS Credit,
   NULL AS Debit
FROM actions

UNION

SELECT
  ToAccount AS Account,
  NULL AS Credit,
  Amount AS Debit
FROM actions

And what trickery queries these two tables for aggregation? Consider these two queries, which is simpler?

-- To aggregate the "classic" table for the Cash account
SELECT
  SUM(COALESCE(Debit, 0)) - SUM(COALESCE(Credit, 0)) AS CashTotal
FROM actions
WHERE Account = 'Cash'

-- To aggregate the former table for the Cash account
SELECT
  SUM(
    CASE
      WHEN ToAccount = 'Cash' THEN Amount
      ELSE -Amount
    END
  ) AS CashTotal
FROM actions
WHERE ToAccount = 'Cash'
OR FromAccount = 'Cash'

What format should your financial system store these in? The answer (like many things) is it depends. But the beauty of our modern computing machines means we don't have to choose! We can store our history in one format and automatically transform it to any other whenever we find it convenient.

Why Use Double-entry Bookkeeping at All?

You've read this whole article and have a better grasp of what Double-entry Bookkeeping is; but I haven't really spoken to why we want to use it. Sure we need to store history to report our finances and make sure we aren't going broke, but why not just keep a snapshot of each account's value at each change? We'll even record which external thing made the change, so we should be fine and can answer all of our accountant's questions, right? I'm here to tell you don't do that. Please do not do that. Double-entry Bookkeeping has been independently invented and re-invented across multiple cultures spanning up to 2000 years! Those inventors found multiple benefits from writing this way:

Double-entries protect against mis-writing
Double-entries protect against mis-reading
Double-entries protect against arithmetic mistakes
Double-entries protect against damaged or incomplete records

But all these advantages I believe are mostly erased by modern databases and computers; automatic-checksums and data integrity algorithms, automatic calculations that never mis-read or make mistakes with built-in error-correcting codes, machines counting cash, machines reading checks, machines communicating financial actions directly with one another. But I see benefits that still make record keeping this way a good idea:

Correcting historical mistakes
Hypothetical alternate histories
Hypothetical futures
Flexible storage and migration options

Breaking news: people still make mistakes. I guarantee that one day the accountants will come to you and say they've mis-recorded something and now they need it changed and that correction needs to be in the past. What will we do if we've only been keeping a snapshot of the account value at each step? Sure we insert the one new value in the past, but that makes all the subsequent history wrong! So then we have to correct all the ones following that correction; don't forget these accounts are live and being updated constantly. Good luck with that.

In a double-entry system, resolution is child's play: find the mistaken action and insert another action with the exact opposite to and from (or credit and debit) and mark that inserted action as happening at the same time as the original. Poof, it's like the mistake never happened (and yet, when asked, we can confirm that indeed that mistake was made and corrected appropriately).

And by its nature of never using mutation ("updates" are done with the insertion of new records), Double-entry Bookkeeping makes moving our data about simple. Have SQL and want NoSQL? Just copy the rows into documents and done. Things changed since the migration? Just check for the new records and copy those. Export to Excel; no problem. Even a text file with lines appended to it satisfies the requirements of our storage needs.

By making our data easy to migrate, we can copy data into a staging environment with hypothetical records to test fixing history or to test potential futures. All made possible by Double-entry. And to those of you saying "just add X" or "modify Y" to a snapshot history, congratulations, you are the latest in a long line to re-invent double-entry bookkeeping. But go ahead, leave that comment, as if you needed my permission.

(Psst, if you want to practice these accounting principles, I am accepting donations at my Buy Me a Coffee. Here's a little graph of what happens: [You]-$4->[Me])

Additional Reading

Hot Swapping Data Models

Nathan Kallman — Fri, 13 May 2022 20:03:32 +0000

Photo by Jandira Sonnendeck on Unsplash

Patrik : "So, we need to track where our employees work. Can we do that?"

Devin : "Like, just what store each person works at? Not too hard. Does anyone work at more than one store? Like a regional manager or something?"

Patrik : "No. That's not possible. Each employee works at exactly one store."

Devin : "Alright, easy enough. I'll work something up this week."

...Later...

Patrik : "Devin! We've been loving the employee tracker you built, thanks. Just one little issue-"

Devin : "Let me guess."

Patrik : "We do need some employees to be marked as working at multiple stores. Can we make that change?"

Devin : sigh "Yeah, let me schedule a maintenance window to make the structural changes to the database-"

Patrik : "No, we can't have any downtime for this app. Everyone needs to run their reports. We need to make the changes without a maintenance window."

Devin : "Uhhhhhh...."

Devin : Googling "How to make database changes with no downtime; Migrate tables without downtime; How to hot swap a data model"

Do not worry Devin! Changing models without downtime, while tedious, can be done rather easily. First, let us look at where we need to get to:

And remember, where we are:

Patrik's requirements pair up to be a one-two punch: change the structure of our database, carry the pre-existing data into the new model, and all without any interruption of service. I have used six simple steps to accomplish just that, more than once, where there could be zero interruption of service and there could be zero data loss or corruption. Here is how I do it:

Implement new models
Write to both models
Backfill old to new
Read from new models
Stop writing to old models
Remove old models

Or IWBRSR for short (alright, alright I'll stop). That's it. That's the whole article. Simple, but effective.

Working through Devin's conundrum, our six steps would work out like this. First, Devin must add the join table we need for the many-to-many relationship between employees and stores. However, Devin does not remove the old foreign key from employees to stores (yet).

With this database structure change made; Devin now begins adjusting the code wherever an insert, update, or delete is made that affects the foreign key from employees to stores to also insert, update, or delete a corresponding employeestores record. (These code changes do not even need to all be in a single release; anything not correctly mirrored between the old and new models will be handled by the next step).

After those changes, Devin has completed steps 1 and 2. Devin can now prepare a backfill. For each relationship that the old foreign key has that the new join table does not have, Devin will create a row on the join table between employees and stores. Since all new activity keeps the relationships that the new join table and the old foreign key have in sync (from the code changes of step 2), once Devin completes this backfill the old model and the new model are perfect mirrors and will stay perfect mirrors of each others' data.

At this point, it may be a good idea to pause for a step 3.5 where we inspect the database to make sure the new and old models are in fact perfect mirrors of each other (like I just claimed).

Once satisfied, we can move on to step 4 and the work will be downhill from here. Devin begins making code changes wherever employees and stores are queried to use the new join table instead of the old foreign key. (Like step 2, this also does not need to be released at once; since the old and new models mirror one another, reading data from one gives the same results as reading from the other until step 5).

Step 5, Devin is almost done! At this point, the new model effectively runs the application (being written to and read from). Devin can safely go to those places they changed in step 2 and remove the inserts, updates, and deletes to the old foreign key. (Again, this does not need to be done in a single release).

To put the cherry on top, Devin goes in and drops the old foreign key column from employees. Completing step 6 and leaving Patrik with what they wanted, with absolutely no downtime!

Now, this was a somewhat contrived and simple example. When doing this for real many, many complications can arise in each step. But, the steps are exactly the same! They work well because each step can be done in parts and redone, little by little, iteration by iteration, until the step works correctly and the next step can be undertaken. So remember, IWBRSR:

Implement new models
Write to both models
Backfill old to new
Read from new models
Stop writing to old models
Remove old models

Attracting & Retaining in a Boring Industry

Nathan Kallman — Tue, 10 May 2022 12:18:17 +0000

Photo by Siavash Ghanbari on Unsplash

I work in a boring industry. Not only do I work in insurance (already boring) I work in claims handling. I know, just writing those words some of you already clicked away. For a fun party trick, answer the what do you do question with "I'm a software engineer handling insurance claims" and watch eyes glaze faster than a Krispy Kreme conveyor belt.

Despite the stigma, I've been here for several years. And plan to be here for more. Why?

Because it has not been boring to me.

And I'll tell you why it has not bored me. From my experiences and observations, these are some things that will attract and retain developers and engineers.

Tell the Stories of their Work

A boring industry's measurements of performance are usually boring. "Oh how interesting, loss ratio has gone down from 87% to 82%", thought no one. Hearing how average claim times dropped from 5 days to 3 days only grabs your attention so many times.

We especially want our work to feel like we have an impact on our world. We feel rewarded when we do good, more than just bagging a big paycheck. Stories like Sharonne keeping her job because she didn't miss a shift while her car was repaired are powerful. Kyle was able to make rent because he was paid today, not in 30 days (a typical, but unacceptable, turn-around time in claims). A criminal organization getting busted on their intricately fabricated fraud scheme? That's better than a movie.

Tell us those stories. Keep us engaged and our restless minds want to stay put.

Let them work on hard problems

Nothing may be more soul sapping to the mind of a technical person than having to do the same thing twice. Our brains crave challenge. If we are not challenged at work, we will find a challenge somewhere else.

Too often boring industries bore us because they lack vision. Decisions are made at only the highest level. And often those decision makers only want to change a few metrics they already measure by a few percentage points. Any engineer or developer faced with uninspired and unqualified prescriptions from above finds a new environment that has inspiration with decisions made by qualified, intelligent people.

Hire people who are smart enough to recognize problems and build solutions at every level, from small to big. Then give them the power and trust to do what they do.

Let them work on other things

Sometimes, the field truly does not have enough challenges for all your employees all the time. This is true and a fair point. But we can still satisfy the need for challenge.

One thing I've long loved about working at Root are the "Hack Days". Every 3 months, for 3 days, engineers are left to work on whatever they like. Read books or whitepapers or blog posts. Build a minigame hidden in the app. Make a tool we use daily just a little bit better. Play with the Javascript framework of the week. Whatever we feel is best for our personal/professional improvement, do it!

Invest in them

Expanding on the last point. Make sure to grow talent, not just use the talent. In the calculus developers and engineers use to decide where to work next, after salary and personal fulfillment, choosing environments that advance our skills and career will take precedence.

Give us a stipend for books. Recommend books and articles. Let them spend some of their time presenting and discussing topics. All these things not only make us better at our jobs; but entices us to stay to keep growing.

Pay them

An obvious and critical factor. I did not list this earlier because even with higher salary than any competitor, failing in other areas will completely sabotage the benefits of higher pay. A massively overpaid employee may still leave if they become so unhappy with their employment that they cannot enjoy the money they have made. Pay alone does not retain or even attract talent. But doing everything else right without good compensation makes those all hollow and worthless. So do pay well.

Also, be honest about compensation. Do not make us bargain and bicker and negotiate persistently just to be paid like our peers. We will find out the new hires are being paid more than us. We will leave. How much does hiring anew cost? No, those are just hard costs; we have not counted the brain drain and morale effects yet. How much does hiring a replacement actually cost? Paying us half that and pocketing the difference might just do wonders for keeping us around. Unlike hardware and software, wetware cannot be replaced so easily.

Share Profits

While we're here, compensating the creation of software with a fixed amount of dollars has always been strange to me. In one afternoon, I'll write something that nets millions of dollars per year (every year, year after year, for decades). The next, nothing, because my idea turned out to be garbage (I have a lot of bad ideas).

And software often provides much more value as a whole than the sum of its parts. So why would we only pay a simple salary to each developer or engineer? How important is that signup page if there's no features afterwards? How valuable is your service if the login is totally insecure?

Rewarding us all when we all have done well builds the trust and incentives to stay and continue performing well.

S T A H P

Nathan Kallman — Fri, 11 Mar 2022 16:23:00 +0000

Photo by Jose Aragones on Unsplash

Just STAHP already!

S ome
T imes
A cronyms (and Abbreviations)
H urt
P roductivity

Sometimes

Before I rant too much, all right, yes. Some acronyms are OK and even helpful. Because (hopefully):

Acronyms (should) save effort in communication.

But whose effort? Communication requires the effort of two parties; senders and recipients (and for most conversations we obviously switch roles rapidly between sending and receiving texts/calls/etc.).

"Good" acronyms save effort from both the sender and the receiver. These are often well known acronyms like ASAP or KISS. They are quick to say; quick to write; and quickly understood because of how widespread and memorable they are (being memorable and not too specific makes them widely useable).

All acronyms save a minuscule amount of effort from the sender. But many drastically increase the effort of the receiver (as they mentally translate; or worse go dig through some archaic document of abbreviations; or costliest of all, ask someone the meaning). These are the "bad" ones that I'd like you to STAHP making up. Just remember when weighing the costs and benefits of your acronym, in business, most communication has more recipients than senders. So you should probably STAHP.

Acronyms (and Abbreviations) Hurt

Each acronym and abbreviation we use adds one more point of confusion and catching up for new members of our teams. After a while, new people nearly learn a whole new language of words in order to communicate with you. Not only that, but acronyms aren't unambiguous even in the same business. Imagine reading this in your email inbox:

PR repo ea Mon by ISO for REV to be uploaded to GH

👁👄👁

What? Pull Requests repossessed each Month by the International Standards Organization for review will be in Github?

No, no, no. Obviously I'm telling you that the public relations report each Monday by the Internal Service Organization for Recruitment, Engagement, and Volunteerism will be uploaded to Greenhouse. Duh.

This example may be a bit over-contrived. But it also falls painfully close to the reality of corporate communication. I wonder how much time we waste each day explaining and decoding these acronyms instead of spending a fraction of a second to say what we mean (and mean what we say). So just STAHP.

Productivity

I will accept some acronym use. But please, STAHP inventing new abbreviations and acronyms for every word you say! It usually wastes more time than it saves. This concludes my rant, thank you for reading (and STAHP'ing 😅).

Do you want someone to STAHP? Here's a markdown STAHP linked to this article for you to use:

[STAHP](https://kallmanation.com/stahp)

Hashnode + DEV

Nathan Kallman — Mon, 24 Jan 2022 20:38:18 +0000

In the midst of taking a hiatus from writing, I've decided to level up my setup to post on a personal blog at my own domain (www.kallmanation.com). I wanted to accomplish a few things:

Have control of where my content is published
Have a backup of my articles
Easily post to both my own domain and still to dev.to
Keep up my Web Monetization that I had on DEV

I found that in Hashnode. Hashnode has settings to automatically backup every post I publish on their platform in my own github repo (giving me number 2 and a little 1); while also letting me host my blog on my own domain (number 1). And as a bonus, my posts will also come up in the main Hashnode feed. They even have out-of-the-box support for Web Monitization!

To cover the cross-posting, DEV (and the forem platform) is fantastic about this. Simply go to the extension settings and set the RSS feed to my Hashnode blog's RSS and check the Mark the RSS source as canonical URL by default option (this will give me the internet juice for any interaction on DEV, while making it nice to DEV users to simply read on their preferred platform).

Now that I've copied all my historical posts from DEV to Hashnode, I hope to blog a little more (maybe not every week though). This post serves as something of a test run of my cross-posting setup. Follow me on DEV or Hashnode and I'll see you around!

Install PWAs in Vivaldi

Nathan Kallman — Thu, 02 Sep 2021 13:36:29 +0000

PWAs are coming to desktop! If you use Vivaldi (like me), then you too can join the PWA gang.

Update: PWAs are now fully supported and no longer "experimental"; you can skip this first step and go right to the installation.

As of today, you'll need to enable the experimental feature allowing installation by visiting vivaldi://experiments/ and checking the box:

Once that's done, visit the PWA you'd like to install, like Google meet. Right click the tab and in the context menu there should now be an option like "Install Google Meet...". Click it and congratulations! Welcome to the future built of Progressive Web Apps.

WAO: How do you get promoted?

Nathan Kallman — Fri, 11 Jun 2021 16:14:50 +0000

Cover photo by Michal Matlon on Unsplash

Wrong Answers Only

Whether getting that "Senior" title, going into management, or going above Senior, how do you get recognized and promoted?

Comment your wrong answer!

WAO: How do you become a "celebrity" developer?

Nathan Kallman — Fri, 04 Jun 2021 18:08:31 +0000

Cover photo by Michal Matlon on Unsplash

Wrong Answers Only

How do you become popular? Gather a following? Be a "celebrity" developer with thousands of followers?

Comment your wrong answer!

WAO: How do you make money with your side hustle?

Nathan Kallman — Thu, 27 May 2021 15:05:53 +0000

Cover photo by Michal Matlon on Unsplash

Wrong Answers Only

How do you make money with your side hustle? Whether that's writing articles (like here on DEV) or freelancing or making your own game: what's the worst way to make money with it?

Comment your wrong answer!

WAO: How do you test software?

Nathan Kallman — Tue, 18 May 2021 19:12:08 +0000

Cover photo by Michal Matlon on Unsplash

Wrong Answers Only

How do you test your software?

Comment your wrong answer!