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.

This is a short story. I hope you enjoy it. It is not like anything else on this blog. If you’ve come here hoping for a new post like my others, I’m sorry to disappoint you. If you’ve come here hoping for other short stories like this one, I’m sorry to disappoint you.

My Folly

“Could you spare a buck for bus fair?”, asked an old man on the street corner. He was bent over and holding a battered cane. Tattered mismatching clothes hung from his thin body.

My budget for the month was already accounted to my last dime. But, what can I do? How can I refuse, when I myself had begged on corners of streets to eat for the day. Shuffling through my wallet I had a ten dollar bill and some change from a morning coffee, “Here’s thirteen dollars. It’s all I have on me. Hopefully that will get you where you need to go”.

The old man smiled, showing his teeth that he hadn’t been able to care for in a long time. I was already running late so I turned quickly and stepped into the street while I heard horns blaring and tires squealing on the asphalt.

I looked up to see what the commotion was about. In front of me there was a large wooden desk. A young man sat undisturbed behind the desk. Or maybe it was a middle aged woman. If they sat in front of me right now I still couldn’t describe them to you they were so incredibly ordinary looking. I saw a neatly stacked set of wooden rectangles behind them. To their right a foot-high stack of folders. To their left a smaller stack of tickets. Immediately before them a folder lay open on the desk. I was seated in a chair in front of the desk and didn’t see anything else around. No street, no old man, no honking cars or trucks.

“Brickmold, reincarnation, or a visit paradise for 10,000 years before being cast into outer darkness”, said the staffer behind the desk without looking.

“I’m sorry?” I answered in confusion. How did I get here? My head had a slight ache.

“It’s too late to offer apologies after you’re dead”, answered the deskperson, “would you like a brickmold, a reincarnation , or a visit paradise for 10,000 years before being cast into outer darkness”, in a tone that I would say was becoming agitated, except it was clear they had said that phrase so many times they were now incapable of saying it in any tone except the monotonic rhythm they’d used so many times before.

“Brickmold?”, I wondered to myself, but apparently too loudly because the deskperson answered.

“A rare choice, but here you go”. They turned around and picked up one of the wooden rectangles. I could see now that it had handles on both ends, and an internal rectangle open to the top and bottom, exactly the size of a brick.

“I’m sorry, but”, exasperated at afterlife bureaucratic misunderstandings apparently being a possibility, I struggled for words, “what am I supposed to do with a brickmold?”

“Make bricks with it”, the deskperson looked at me for the first time, up and down, “that’s pretty self explanatory in the name, ‘brickmold’”.

“Right, but”, I trailed off, not knowing how to argue anything. Or what even the point would be. I looked to my right and saw a second desk I hadn’t noticed before. Staffed by another deskperson, identical in ordinariness but somehow distinct from my deskperson. Sitting in front, a man I can only describe as gluttonous. You may think I’m being mean or uncharitable in my description. Please trust my goodwill that if you looked upon this person, ‘gluttonous’ would be the most charitable description you could muster. For I do not mean simply outward physical appearance. This man’s demeanor, his very eyes looked hungry, hunting for the next convenience to consume.

The same choices were rattled off to the man in the same monotonous rhythm as I had. And the man answered quickly, “a visit to paradise! Obviously, does anyone pick anything else?” Promptly his deskperson picked up one of the tickets at their desk and handed it over to the man.

Still wondering what to do I now looked to my left and saw a third desk, a third deskperson, and a sharply dressed woman in a suit sitting before it, seemingly ready to sign some multimillion dollar business deal. Again I heard, “Brickmold, reincarnation, or a visit paradise for 10,000 years before being cast into outer darkness”, rattled off by her deskperson.

“Reincarnation”, the woman proudly answered, as if she had hacked the system and had it all figured out. “What are my choices?”

Her deskperson began going through the stack of folders to their right, “I have multiple Oriental positions open, let’s see, an Eastern European farming family too. Oh interesting, I have an Icelandic opening, don’t see that everyday”.

My deskperson caught my attention by speaking, “You can’t stay here forever. Please take your brickmold and move along”, holding out the brickmold for me to take.

I stood and took the brickmold they offered to me. Not quite sure where exactly to ‘move along’ to, I turned around to see if there was a way forward that direction. I saw an endless field of light brown clay. I turned back and saw more clay. Clay to the left. Clay to the right. Flat and soft clay. No desks. No deskperson. I was alone.

I was alone in a field of clay with a brickmold in my hand. High above me, faintly in the clouds, I could see a shining city. I thought that must be heaven. And the purpose of my brickmold became clear, I hadn’t measured up in life so I must close the gap in this purgatory after death. One brick at a time.

I started my first brick. Filling the mold with the clay. Slumping out the damp brick on the ground. My cornerstone has been laid. Or is it a corner brick? I’m no mason. But I knew I couldn’t stack wet bricks on top of one another. I wondered how long it would take to dry them.

I began making many bricks, ten in a row with ten columns beside. After making one hundred bricks in this way, I returned to my first brick to see if it was dry. Being still wet, I made another hundred bricks in the same way before returning again.

I made nearly one thousand bricks in rows and columns before the first brick was dry to the touch. I was still no brick expert. Surmising there may be a difference between dry and fully hardened, I decided to continue making bricks before using any. I must have an excellent foundation, rushing at the beginning may double the work near the end.

After making ten thousand bricks, I returned to the first row of bricks to begin the tower. I realized I had no mortar. Nor any idea how any sort of mortar could be made. The only thing around me was clay. And besides I had no tools for laying bricks with mortar. Even if the tools and materials all fell on my head from heaven, would I even know how to use them?

After long consideration, I thought there was nothing for it than to just dry stack these bricks in a pyramid shape. Hopefully that would be stable enough. I knew I would need an immense base. So my first thousand bricks I laid in a straight line. The next thousand I laid beside it. I realized I should offset my bricks but, not having half-bricks I wondered how. Wedging a brick between two others, jutting out about halfway, and striking it with a fourth, I was able to make a decent pair of half-bricks.

After laying these two thousand bricks I realized that, while an impressive tower it would make, it would be a paltry height in light of what was required to match my goal. I returned to making bricks by the ten thousand, laying the prior batch in my tower after setting a new one to cure.

I laid one hundred thousand bricks end to end. It now took half the day to walk its length. Although, “day” is not the right word. There was no night here. I was never hungry or thirsty. Always tired, but never needed slumber, nor even seemed to have the ability to sleep when I laid down. There was plenty of time to think while walking. I could only mark the passage of time by the shadows the bricks cast. Though it seemed ambiguous where the light came from, feeling like it came from everywhere all at once. The subtle shadows pointed first on one side of the line of bricks and later the other, eventually circling back around to the start.

I thought about the dimensions of my tower. How high would it be? I couldn’t quite remember my geometry. I drew out a pyramid in the clay. I drew the height as a line coming down. I didn’t want to reinvent geometry, but had a vague remembrance. I drew the pyramid again, this time with the base exactly the length of my two feet, one in front of the other. The height I drew and put my foot beside it, matching its length exactly. So, my pyramid would be about half as high as it was wide, depending on the angle I chose to build to. I started to think a pyramid half as high as half a days walk wouldn’t be nearly tall enough.

I walked back to where I was making new bricks, determined to make a bigger foundation. I laid a second hundred thousand bricks. Instead of making bricks in one area and carrying them to place, I now simply made bricks adjacent to where they would be placed. I waded off the end of my tower edge in this way, making brick after brick, one after another. I didn’t bother counting now, I would go mad if I tried. Instead I counted by days making bricks. I knew ten thousand bricks took slightly less than a day for me to make, since I’d gotten so much practice. Doubling the side length of my tower would take over two weeks just to make the bricks.

But what is time in this place? I doubled it and doubled it again plus some extra for good measure. I now had to walk a week straight to cover the length of this one side of my tower.

Save those second thousand bricks I prematurely laid, after all this work I had but one row of my tower. Not a whole layer, just one row of one layer! But what is time in this place? The deskperson didn’t mention any time limit like the visit to paradise had.

I took my brickmold back to the start. I began making the bricks for the second row. Brick next to brick, all drying in the light, marching off to infinity. Or more accurately, a few days walk. Once I reached the end, I walked for a week back to the start and began placing the now well cured bricks in their row. As I walked back again, as I had left my brickmold at the start, I realized I was spending an extra two weeks walking for no reason. I ought to think of it more like mowing a yard than writing lines of prose, making bricks all the way down as well as all the way back before placing bricks back and forth so there would be no walking without working.

I did just that for a while until a difficulty arose. As I worked deeper into my tower’s foundation, I had to walk farther back to the edge where I dug more clay for bricks. Not wanting to dig a hole in the middle of my towers foundation! Progress slowed with each row laid. Halfway through the base of my tower I considered trudging the other direction to where the final edge of my tower would lie. But hiking three days straight into a landmarkless field of clay made me nervous. Once I lost sight of my tower, how would I find my way back? How would I measure the distances correctly? Better to slog through the progress I had than lose all of it.

It took several years to lay that first layer. But it was done. I rested in the knowledge that the first layer had the most bricks in it, so the next layers will become easier and easier to finish.

I began the second course of bricks. For variety, I placed the bricks at a ninety degree angle to the first course, so my first row of the second layer ran across all the rows of the first layer. It was a breath of fresh air being able to make and lay bricks in such a rapid succession again, the way I had been able to years ago at the start of my building when I made bricks down and then back to then lay them all the way down and then back to do it all again.

A few weeks less than several years and I finished the second layer of my pyramid to heaven. A few weeks less than that and a third course rose from the ground. There was a point a few layers up where I spent exactly one year to lay one layer. The pyramid was rising at an exciting pace now. Well, exciting for one already decades into solitary madness.

I neared the top of my pyramid now. A ten foot by ten foot square was the summit. And my goal shimmered a clearly unreachable distance away still. A measly five additional feet to cap this pyramid off would be as effective as a single grain of rice given to a starving orphan. Or as effective as those thirteen dollars I gave to that beggar? Discouraged, I laid on the top of my tower. How long had it been? A century? More? Why would I think penance so simple or purgatory so short?

I descended to the base of my tower. Along two edges I began filling in the great trenches I had dug clay out of while making bricks, preparing a wider foundation to extend my pyramid. I added row upon row of bricks to these two sides. Each row at the bottom, many miles long, would add a few inches of height to the top. And I built more and more. Clay, bricks, time; I have thought all my thoughts and only have routine left. Put clay in the brickmold. Carry a brick. Place a brick. Walk and walk. The centuries wound on as I built a larger pyramid with my first pyramid as its corner.

Again I stood at the top. Again heaven was out of my reach. I descended further. It took a full month to reach the bottom. I made more bricks. Like a sole surviving ant, toiling on their deserted colony’s hill, I built more. Why did I continue? What Sysaphusian task had been born of a single word? “Brickmold”, I had said. Why not visit paradise for this whole time? Or reincarnate? I would rather be abused for a lifetime than suffer this another millennia. Or just send me to Hades. Maybe a nice crow could come peck my liver out everyday, that sounds more enjoyable than this. “I don’t mean that”, I apologized to no one in particular. I still had a chance after all, hadn’t I? Diligence and hard work, that’s all I needed. A millennia turned as I built a larger pyramid with my second pyramid as its corner.

Again I stood at the top. Now on a mountain Everest would wilt under. Now a monument Olympus Mons would be shamed beside. Now a tower Babel’s architects would covet. Again heaven was out of my reach. Again I descended further.

“I can’t do it”, I screeched while trodding down. I could not continue this insanity. I could not move another mountain to gain a single inch, followed by two mountains for a second inch, it was too much. Perhaps I had missed something.

At the bottom I began experimenting other building techniques. I tried making a single column, which was stable enough but I had no way of climbing it. I tried making a spiral staircase around the column but either the upper steps kept collapsing onto the lower steps, since nothing supported the outer edge, or I destabilized the column by my weight being so off center. I attempted an open circle of bricks, like a well built upwards. If I put some of the bricks in sideways to make small footholds I could climb up the interior. Except there was no way into the base of this well-tower to begin the climb.

I attempted ways to make arches, thinking I could make an entrance. If I first built a supporting scaffold of brick, I could make an arch big enough to crawl into after laboriously removing the scaffold bricks. Making six archways with some extra interior thickness of the columns would make a near circular base that I could get into to climb the well-tower. Making the interior as narrow as possible while still allowing easy climbing and descending would reduce the bricks needed to build. Also, while experimenting I realized I needn’t make the circle of bricks solid. I could easily leave half-brick gaps, stacking the next brick so it just barely bridged two below it, alternating the gaps. This saved a great deal of bricks, which would be extremely useful with how long it took to reach the top of the pyramid.

And so, I trudged back up towards the top of my pyramid to build this new tower on top of it. I could only carry two bricks at a time. Not wanting to spend a decade building just the six arches for me to crawl into, I began borrowing bricks from my pyramid. I could remove some and leave the pyramid a step pyramid like those of the Aztecs rather than the smooth pyramids of Egypt I had started with.

Brick by brick I built this new tower from the top of the pyramid. I reached a sickening height. Then dizzying. Then so absurdly high that it felt like I was standing in a well at ground level. The clay ground stretched out in every direction and my pyramid was so far down beneath me it was almost imperceptible. I gazed up at heaven high above me. An uncomfortable thought entered my mind. I descended further. It took over a year to reach the bottom of my tower now. I had stolen every brick I dared from my pyramid.

I made two bricks, then I picked up the two bricks destined for the top that I had made years earlier for this day. I had learned how to climb the well-tower with two bricks. I looked up at heaven again with the same uncomfortable thought.

While still standing on the clay, I stretched out a brick in my hand. At arms length, the brick perfectly covered the city. Perhaps I could gauge my progress. If objects farther away appear smaller, the closer I get the larger it will be and the less my brick will cover when at the top of my tower. I began my heavenbound ascent.

Another year later, I stood again where two years earlier I had just finished laying a circle of bricks in my well-tower. Before placing the bricks I had carried all this way, I raised my arm, just as I had done at the base, with brick in hand. At arms length, the brick perfectly covered the shining city, just as it had at the base. I was no closer. I screamed. I yelled like a she-bear finding a dead cub. Like an air raid siren mounted atop its post.

I slung the brick off the edge with what remained of my strength then collapsed onto my face, slumped over the edge of my great folly.

A voice spoke to me from the other edge of the circle, “Why do you weep, my child?”

“I can’t do it myself!”, I howled before I even wondered how there was a voice besides my own. Anguish, true despair, suppresses all logical questions. And it had been so long since I’d spoken aloud, it was a wonder I had a voice still. That I still remembered the language I learned so long ago. Was this my language? It felt strange in my ears. Yet I understood the words perfectly.

“You never could little one”, He said with such searing truth it cauterized my wounded heart. But spoken with such tender love, like a cool salve on a burn. “Do you know me?”

I looked up at the voice. But I could not look. He was blindingly bright. I could have looked directly at the sun more easily than to look upon this man.

“How can I know you?”, I said, still with some bitter tears on my tongue. Hanging my head back down.

“You gave me thirteen dollars on the street corner before the accident”, I shot my head around to look at the man, who surely couldn’t be the same haggard and bent over old man I had given that pittance to those millennia ago. He continued, “and I remember you helped me cross the street in front of the courthouse when my eyes had failed me”. That had been a middle aged woman, they can’t be the same person. “And I was a hungry teenager, turned out of his home the day after Thanksgiving. That leftover Turkey you gave me on the ride to a safehouse filled me like you can’t know”. The man trailed off as though he had thought of seven more examples, but instead of listing them he simply looked at me and asked again, “Do you know me?”

“How can I know you?”, I answered, still in confusion and doubt.

“Believe. Know by faith what you have not seen with your eyes”, and without looking away from me, he asked again, “Do you know me?”

I knew, and was afraid to know. “How can I know you?”, I answered the third time.

“Call on my name”, he said simply.

I knew. I knew I had fallen short. I knew I could not do it on my own. I knew there was no other way. I swallowed and hung my head, “Christ Jesus, please”, I trailed off with too many words to say. He answered, “Rise up. Pick up your brick”.

The brick I still had was now solid gold. I obeyed, but struggled under the weight. I slowly and carefully crawled out of the circle of bricks, up onto the edge. He instructed, “Give it to me, my child”. I gave it to him. “Look behind you”, he said and I turned around. We were no longer perched atop a lonely, useless tower, but on a solid street paved with gold.

On each side there were houses. Beautiful and big. But not uselessly large like mansions of earth. They lacked no rooms needed, but no useless rooms were present. Each room large enough to enjoy without being the cold, uninviting, overly large rooms the wealthy of the world pretend to own. The houses were just as close as three best friends would want their houses to be together. Never so close as to feel crowded. Never so far as to be inconvenient for a walk on a cool day together as neighbors.

In one direction the road continued over a small glassy stream before branching into more streets. The other, it ran a few paces before trailing off where it clearly needed to be paved further.

“Take your brick and place it”, he told me. I took it, ready for the weight of solid gold, but it was now lighter than imaginable, lighter than the clay bricks I had moved so many of. A foam brick even would have felt heavier in hand. I happily placed it, extending the pathway in paradise.

“So heaven is”, I wondered if such silly questions were allowed, but asked anyway, “still under construction?”

“I said I would prepare a place with many rooms”, he answered, “did I say I would build the Kingdom of Heaven alone?” He smiled at me.

I pondered a great many things. How meaningless all the things I had done, both in death and in life, had turned out. But yet what impact they all could have when given to him beside me.

“Before you come to rest here, there is one more thing you should see. Migdalel will take you.”

And beside me another bright man stepped into view. Though less bright, he was still as bright as the sun. I squinted at the man to see. Was this my deskperson who gave me that brickmold? Without a word Migdalel gently touched my arm and we were away.

We alighted in a hospital room. The person in the bed was unrecognizable. To put it simply, they looked like they had been run over by a truck. Many machines hooked to the patient in the bed beeped and whirred, clicked and cycled. Dripping medicines and saline into the patients veins. Pushing air into the patient’s lungs before releasing it.

My breath left me as well. The patient in the bed was me. “Am I,” trailing off, I changed my question, “Was any of that real? The desk? The brickmold? The tower?”

Migdalel answered, “You aren’t able to understand my answer yet. Trust in time all this will make sense. ‘With the Lord one day is as a thousand years’, as it has been written.” Migdalel continued, “The doctors refer to your body as ‘brain dead’. Silly. If they had half a brain between them—anyway, you weren’t brought here to listen to me. They’ll be disconnecting their life support machines soon, and what’s left of you on earth will follow your brain.”

I looked upon myself. My battered body. Brain dead. But not dead? Then I had a memory of a parable my Lord once taught of a man finding the truth about life only after death, like me, and he had asked for someone to be sent to tell his friends and family. Maybe, like in that story, it wouldn’t make a difference. But maybe.

A boldness welled up within me that I didn’t recognize. “Didn’t he raise Lazarus from the dead? Didn’t he say faith can move a mountain?Are there not more people to be reached here in life?”

“‘The harvest is plentiful, but the laborers are few’”, quoted Migdalel, “if you are asking for more time on earth, that is not for me to grant. It will be difficult, but you might lay back down into your body and pray to our Lord. I will wait with you”.

I laid myself down. After the out of body experience this “in body” experience was even more surreal. I heard doctors enter the room, but couldn’t see them. I couldn’t move my eyelids. They began disconnecting me. My breathing stopped. My heart was slowing down. I faced an impossible thing, to live in spite of dying. But I had faced an impossible task already. And this time, I was not alone. “Christ Jesus, please”, I began my prayer.

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 hasn’t been written, or what once was written and now is lost. But there is still no way for us to find what we don’t know how to look for. Unless, of course, you’re 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:

1. Is this mostly new to me?

2. Is this useful to me?

3. 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.

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:

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:

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.

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:

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:

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:

1. Double-entries protect against mis-writing
2. Double-entries protect against mis-reading
3. Double-entries protect against arithmetic mistakes
4. 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:

1. Correcting historical mistakes
2. Hypothetical alternate histories
3. Hypothetical futures
4. 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

• Accounting for Computer Scientists
• On Double-Entry Bookkeeping: The Mathematical Treatment
• Wikipedia: Debits and Credits
• Wikipedia: Accounting equation approach
• Wikipedia: Accounting equation
• Wikipedia: Double-entry Bookkeeping history

...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:

1. Implement new models
2. Write to both models
3. Backfill old to new
4. Read from new models
5. Stop writing to old models
6. 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:

1. Implement new models
2. Write to both models
3. Backfill old to new
4. Read from new models
5. Stop writing to old models
6. Remove old models

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.

Some
Times
Acronyms (and Abbreviations)
Hurt
Productivity

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)

1. Have control of where my content is published
2. Have a backup of my articles
3. Easily post to both my own domain and still to dev.to
4. 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!

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.

De Morgan's Theorem comes in two parts, each in the same pattern:

!(a && b) == !a || !b
!(a || b) == !a && !b

Why Does This Work?

It may not be immediately clear why this works. Why can we just swap between and 'ing, and or 'ing, if we twiddle with the not 's? One way to think about it is that and, and or are "twiddled" opposites of each other:

and has three falses and a true while or has three trues and a false, and the order is also "twiddled" to be reversed.

First not 'ing the input can be thought of as reversing the order of the output:

Now we can see this output is the exact opposite of an or against the opposite inputs. So:

!(!a && !b) == a || b

Which is just a rearranged version of one of the relationships above:

!a && !b == !(a || b)

And giving the same treatment to or first instead of and first will yield the other relationship.

But Intuitively Why Does This Work?

Well, if an apple is not red and not green, would you say that apple is also not red or green? You probably did not even question that those two statements are equivalent: not red and not green has the same meaning as not red or green. But that's exactly the De Morgan's Theorem we worked through above!

!red && !green == !(red || green)

And if that apple was not not red nor not green; you may eventually see through my double negatives that I mean to say the apple is red and green.

!(!red || !green) == red && green

I propose that one of those statements is much more readily understood (both in code and in english). And why De Morgan's Theorem is worth remembering: cleaning up sometimes confusing boolean expressions.

What's This To Do With Wireworld?

Look again at the NAND from the last post in this series.

Now let me show you what an OR and a NOT look like in Wireworld.

Look back to the NAND and do you see the pattern? My NAND is actually just an OR with its inputs first NOT'ed. That's exactly what De Morgan told us!

!(a && b) == !a || !b

If you've spent any time programming, you may recognize the "big three" boolean operators: AND, OR, and NOT (often written &&, ||, ! in many programming languages). Together these operators are functionally complete, meaning they can be used to build any boolean logic. Combined with some sort of memory, functionally complete operators can be used to build a turing complete system.

What if I told you we need only one operator to be functionally complete? That's right! All you need is NAND (short for Not AND; !(x && y)). But don't trust me, let me show you.

Proving NAND is all you need

NAND is NOT

You've seen the animation of a NAND in a Wireworld above (NAND-imation anyone?). What would happen if instead of two inputs, we tied them both together as one input?

Notice how this new operator constantly outputs until an input is received and then it stops (aka NOT logic). In JavaScript, if we had a nand(x, y) function, we could make not() like this:

const not = (x) => nand(x, x);

Look at NAND's truth table where both inputs are the same:

Looks a lot like NOT to me! NAND is NOT.

NAND is AND

Look at NAND's full truth table compared to AND:

It's perfectly inverse (that is the definition of Not AND after all). If only we could NOT the output of our NAND, we would have AND... if you read the last section, that's exactly what we have! Just put the output of a NAND as both inputs to another NAND and viola! an AND appears:

Again to relate this to code it might look something like this:

const and = (x, y) => nand(nand(x, y), nand(x, y));

NAND is OR

Perhaps the trickiest one yet. AND and NOT were fairly obvious looking at their truth tables. But OR?

OR is tantalizingly close to NAND. They both have three outputs of true and only one case of false. But the tables are backwards! What are we supposed to do with this? What if I showed you a table with the opposite inputs:

Does that pattern look familiar? If we NOT our inputs first (using the same NAND as NOT trick) and put those as the inputs to our NAND, we'll get an OR!

We'll finish out our code examples:

const or = (x, y) => nand(nand(x, x), nand(y, y));

_(We just did DeMorgan's Theorem a_ very cool trick for making boolean code more readable; but we'll talk more about that later)

NAND is all you need

If you accept that AND, OR, and NOT are functionally complete, since NAND can build each of those three things, NAND, all by itself, is functionally complete!

So yes, NAND is all you need... but please don't write all your booleans using only NANDs. This is for your edification and education.

Why should I care?

Problem Transformations Solve Problems

What is the difference between a Bubble Sort and a Quick Sort? They will both give an equally sorted output after all. The importance comes in performance. Because while they are logically equivalent they are not operationally equivalent; one of them will finish faster when a physical computer executes the sort.

Many, many things in the business of software development see drastic improvements from transforming the physical operations while keeping logical equivalence. The better we become at this skill, the better programmers we become. (One way to become better is seeing examples, like this).

NAND Runs the World

It just so happens that in real-world computer chips NAND is one of the easiest things to build. If you've ever heard of 3D NAND, you now know what that NAND stands for. And when your code works the first time around, thank a NAND gate.

It's Just Cool!

Who would have thought that just one operator can run the whole world?

A Wireworld is similar to the famous Game of Life. An infinite world of square cells, each in a distinct, finite state. But unlike boring life that has only two states: alive and dead; Wireworld has four! That's like... twice as good?

A Wireworld cell could either be: nothing, a conductor (wire), an electron tail, or an electron head. An electron head always becomes an electron tail which always becomes a wire, while a wire will stay a wire unless exactly one or two neighbors are an electron head, in which case it will follow suit (and nothing continues to be nothing).

You can see those rules in action in the animation above. You can also play with those rules over here: wireworld.klmntn.com (warning, it's only somewhat useable on mobile)

The Making Of

Every three months, Root sets aside three days (called "hack days") for all its engineers to work on something of their choice. This time around I wanted to have some fun and also learn a little about Svelte (Root mostly uses React & React Native). So I chose to make a browser-based Wireworld using Svelte! (repo)

Decisions, Decisions, Decisions

Framework

How did I settle on Svelte? I'm already working in React and Vue and have worked a little with Ember long ago (I've even played with the now abandoned Cell.js). Angular seems to be a different flavor of the React/Vue/Ember gang. Svelte though looks to have some novel ideas that I wanted to expose myself to.

Graphics

There's really only three options for displaying anything on web:

1. HTML + CSS
2. SVG (+ light CSS)
3. Canvas

The nature of a Wireworld's rendering requirements makes HTML + CSS a no-go. Canvas honestly might be the most appropriate as it can be optimized for high-frequency re-rendering. But future things I'd like to build would work well in SVG and I've already played with Canvas in the past, so I wanted to learn about graphics in SVG!

World Loop

At the base of the simulation, something will need to decide what the next state should be based on the current state. This could be done in a procedural way with a switch / ifs or functional way or object-oriented. I've written about the similarities and differences before. I chose an object-oriented approach where each cell will be an object that responds to nextState; call nextState on all the cells and the world's next state has been found.

What I Learned

SVG Just Works

And by this I mean two things. First, SVG does not present a lot to learn above and beyond HTML + CSS (compared to the whole drawing API of a Canvas). I just put SVG tags right into Svelte components and, bang, graphics.

Second, SVG solves some of my biggest pains of drawing on Canvas. On Canvas, everything needs to be constantly erased and redrawn and if I ever want to move my viewport I'll need to do all the math to scale and translate my graphics (or learn and use another library to do it for me). With SVG, one viewBox attribute on the top <svg> tag handles all the scaling and translations (written by people who know a lot more about graphics than I do and offloaded to the browser so no JS needs spend time on those calculations).

Unless you have a very high paced game or some 3D graphics to render, I would recommend going down the SVG road.

Svelte Stores are Great

I've always heard that Svelte is good because it compiles down to vanilla JavaScript not needing virtual DOM, making it faster. But the state management available with Svelte's stores is fantastic (suck it Redux). The derived stores open even more possibilities. But by far my favorite are the custom stores: I absolutely love the patterns that opens up.

The State of Capturing Input Sucks

I had no idea how bad listening for things like key presses and dragging events are today. Given how nice and fairly standard a lot of the APIs across browsers and platforms have become, I was shocked at how rough this space is. I think if I had to do this again, this will be one area where I defer to a library (like hammer.js).

Svelte Seems to be Lacking Tutorials

There's plenty of examples over on the REPL site. But those examples have next to no explanation on how they work; nearly every search I tried led me to one of those examples, so it was a bit of work piecing the things together, looking at docs, and doing experiments to get things working.

Wireworlds Like to Light On Fire

Very often a misplaced wire or extra spark will cause my whole creation to devolve into closely packed electrons shooting every which way. This happens shockingly easily and I think makes a wonderful allegory to why our real computers are so hard to make and keep working correctly.

Things To Make and Do in a Wireworld

If you just want to go play with it now: wireworld.klmntn.com. First, go check out the few examples already included. A main building block in Wireworlds is the "transistor":

Like a real P-type transistor; our Wireworld transistor allows the signal to pass when nothing is on the gate, but blocks the signal when the gate is "on" (it even looks like a transistor diagram).

The next piece used in most designs is a signal generator:

Any loop of any shape with an electron moving around it can continuously emit electrons at a regular interval.

And go have fun! Export your creations and comment below.

Vim (the software) kinda sucks

I'll be honest... Vim kinda sucks.

Selecting, installing, updating, and resolving conflicts between all those plugins takes a lot of time.

And then you'll also want to write your own plugins and set up macros and shortcuts and ...

Yes, this makes Vim incredibly powerful and configurable. But also, makes it a nightmare to actually get into a useable state sometimes.

Vim (thinking) is amazing

So if Vim (the software) sucks so much; why do I use it professionally every day?

For one, at Root there are several Vim users that all share a common configuration; spreading that setup cost among multiple people.

For two, after learning Vim (the thought process) every other text editor felt cumbersome and slow.

Vim (thinking) literally changed my brain; it made me faster even in non-Vim editors. Even though I felt slower (than Vim) going back to my previous editors, I was actually faster than my pre-Vim days!

What is Vim thinking?

Today's code "editors" are actually mostly code "writers". What I mean by that is their main mode of interaction is to write new code. Their only means of "editing" is a pointing device, deletion, and a single buffer to hold content being copied (or cut, that special copy/delete combo) from one place to another.

Anyone who has used Vim for more than 10 seconds knows Vim starts in a mode that does not accept typing in new code. Why? Because Vim is an editor not a writer. Everything about Vim is geared towards the mutation of code; rather than the creation of code (and don't we mutate code far more than write new code?).

Let's take this psuedo-code example:

if (!DevelopmentEnvironment.usingVim) {
  const vimCandidates = ["vi", "vim", "nvim", "vim_plugin"];
  const randomIndex = randIntBetween(vimCandidates.length, 0);
  DevelopmentEnvironment.setCurrentEditor(vimCandidates[randomIndex]);
}

Hopefully clear logic: if you are not using a Vim-ish editor; attempt to randomly assign a Vim-ish editor to your dev environment. But whoops! I have a little typo: randIntBetween is supposed to have the smaller number as the first argument. How do we fix this?

In non-Vim editors, I might do something like:

1. Move my hand from the keyboard to the mouse
2. Track the pointer to reach the location between the 0 and the closing paren ) and click
3. Move our hand from the mouse to the keyboard and backspace once
4. Type our vimCandidates.length (maybe we have autocomplete to help a little)
5. Move our hand from the keyboard to the mouse (again)
6. Track the pointer and click to select the first vimCandidates.length
7. Move our hand back to the keyboard (again)
8. Backspace and type the 0

With slightly more of what I call Vim thinking, I would:

1. Move my hand from the keyboard to the mouse
2. Track the pointer and click to select the vimCandidates.length
3. Cut the text (without having to move my hand from the mouse)
4. Track the mouse pointer to the beginning of 0
5. Paste the text at that location
6. Still with my hand on the mouse, select the 0 and cut the text
7. Track back to before the comma and paste the 0

Let's pause to examine the difference. In the first case we moved our hand between the keyboard and mouse 4 times as much! And you may think, "What's the big deal? My mouse is a few inches away" (I know I thought that). Well what if your app was making 4 network calls when it could be making 1 or even 0? Would you not immediately refactor to be more efficient?

Now see what I would do in Vim:

1. Use j or k to move to the third line
2. Type fv to move direcly on the start of vimCandidates.length
3. Type dt, to cut the content from there until the comma
4. f0 to move onto the zero
5. vp to highlight the zero and paste over it with vimCandidates.length
6. F, to move back to the comma
7. P to paste the zero before that comma (because when pasting over in step 5, it also copied the 0 as I was pasting)

In this case I have not moved my hand to the mouse at all! Even more I haven't moved my hands from the home row. And many are scoffing at this point, "Why would I spend the time to memorize and type all those commands to save 5 inches of movement?" To that I say, did you "memorize" how to spell apple or orange? When you type them do you mentally go through each letter: A then p then p then l then e; to control each finger to type those letters? (If so this post isn't for you... take a step back to learn better typing) No! When I type apple, mentally I'm moving my fingers in a single motion "apple" not five distinct movements to type "a-p-p-l-e". And after a few weeks of using Vim, that's what I do there as well: I don't type "f-v - d-t-," I type "fv dt," as though they were words in a sentence.

So what do I mean by Vim thinking? Look back to our first "edit" strategy: I deleted and retyped my code. Compare to the second and third: I edited my code to rearrange the function arguments.

Now do you see why Vim does not start in a mode to type code? It is an editor first; writing is a secondary function.

Edit, Don't Write

Vim was difficult for me at first. Partly because of the dreaded learning cliff. Mostly because I did not understand how Vim wanted to be used.

Footage of me trying to use Vim, 2012, colorized

So I put it down. Then when I was onboarding at Root, I sat down with someone who knew Vim thinking. It was a revelation watching them work. There was still the learning cliff to overcome, but now I had seen what sat atop the hill. And I wanted it.

A writer will delete and retype. An editor will transpose, cut, pattern match, and find a path of least change. A writer wants faster typing. An editor uses less typing. A writer offloads writing to the machine. An editor melds the machine and the mind. A writer sees what they want. An editor sees the path to get where they want.

Use an editor, not a writer.

Vim Thinking is Machine Thinking

Vim provides a full language of editing semi-structured text of any kind. Like the letters in these words form into sentences transferring my thoughts to your mind; the commands of Vim stack into words, which flow through sentences, and paragraphs, perfectly telling my pile of sand and copper how to rewrite its code.

In Vim, I'm never more than a few keystrokes from code I've imagined to a coded reality. Being that close means I can iterate through my ideas more quickly. Most of my ideas are bad to awful; throwing them away as quickly as possible is the best thing I can do with them.

In a recent article, I talked about how the process of making something directly affects the results. Code written with Vim thinking has unique qualities from code written in other ways. Physically enacting the same mechanics that my computer uses to interact with its world gives me an empathy and understanding of it. That understanding makes code easier to read. That understanding makes code easier to write.

Getting into Vim Thinking

Pick a flavor: a plugin, neovim, vim. Don't customize it (yet), just dive in. We want to start thinking in Vim, not die in the quagmire of configuration.

If you can learn about two dozen "letters" in the language of Vim, you will be at least as quick in Vim as any other and over the main cliff where patterns will start to emerge making learning easier. Funnily enough that's about how many letters are in english; so if you can read this, I know you can learn Vim thinking. Here is my Vim DAG mapping the concepts covering 80% of what I use in Vim.

And here is the challenge to get you Vim thinking:

1. Go back to that psuedo-code above, copy it into a file and open with Vim; make the correction; and refactor that psuedo-code into as few lines as possible.
2. Extra challenge: never enter insert mode (don't use i, o, a, or c from the diagram).

If you do that (especially with the extra challenge) I think you'll have enough of a taste of Vim to understand this whole rambling post I call an article (and probably enough to want more Vim in your life).

Going Deeper

So you want more Vim now? 😈 Good (secretly high-fives Iviminati friends). There are three more things that seriously leveled up my productivity in Vim (that I now miss in most other editors):

1. Multiple copy/paste buffers
2. Recording and replaying Macros
3. Basic Regular Expressions for searching (and replacing)

Have fun!

Speaking of college, there's a particular page in a particular textbook I think about often. Not for its content, but rather as an analogy to a concept I struggle to express any other way.

I want to dig deep into that concept today. If you came for a squabble on scribbling out software; you may leave, this is not the post you are looking for.

First, the page I think about, page 56 of Introduction to Graphics Communications for Engineers, Fourth Edition by Gary R. Bertoline (ISBN 978-0-07-352264-7)

Look through those diagrams of how to write out letters and numbers. That's probably not the way you were taught your lettering and almost certainly not the steps you follow when writing today (I definitely didn't). But how legible is your writing?

The Crafting Process Directly Correlates to the Result's Quality.

The steps and tools used in making leave indelible marks on the end result. Really I'm just retelling Conway's Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

But now I have an analogy for why Conway's Law is true. Look back at each of those letters; do you notice a pattern? Pen strokes are limited to going down and to the right (not strictly, but generally). No coincidence those are the directions a right-handed writer has most control over.

Could we write letters just the same without following such a stringent rule set? We could try. And we would have good results for a little while. But once we stopped focusing our handwriting would degrade once again back to our old pattern.

An organization can ship a system designed differently than its own structure. This happens regularly. But it will quickly devolve into matching the organization structure just as our handwriting devolves to the natural forms our grip and strokes encourage. Changing the strokes taken makes it natural to fall into that particular legible style. Changing organization structure makes it natural to produce software of a particular style.

Beware Labelling Every Cost as a Problem

Go try writing using those instructions for a minute. It will be very slow at first. After a few minutes you should have a little rhythm and won't need to look at the instructions much.

But this stroke pattern will always be slower than others. The added guidelines to only go down and to the right forces the hand to lift and move the pen more often.

This is a cost not a problem. Problem's can be solved. Costs are the requirement to obtain what we want. We want legible handwriting. The cost is writing slower to follow the guidelines.

I have often seen discussions start up around all sorts of "problems" looking for any manner of "solution" in the business of software. I can hear them now, "If we could go up and left, we could write letters so much faster!", but that is not a problem; that was intentional!

I truly believe that particular habit, more than anything else, locks larger and older companies into all the odd behavior, poor customer service, and lack of innovation we see of them. They have straight-jacketed themselves with decades of "solutions" to "problems". But those "problems" were just the price of being the best in the business!

Monitor Output

I know of no way to truly predict the final results of changing a making process. We have gross heuristics (fist gripping a pen will be less precise than gripping with forefingers; agile-ish practices see better utility production than waterfall-ish practices).

But to truly know? Specifically? We must try it and observe the results. In software development, this means the practices of the team (agile, cross-functional team-members, red-green-refactor TDD, etc.). The output to observe being the code written (if the people deciding what practices should be used can't understand the code output*, you have a Big Problem™).

Is the code produced of a similar quality? Maintainable? Extendable? Bug-free? Robust to unexpected situations?

No? Congratulations, the "problem" you solved was actually the price of quality.

* Don't forget understanding requires communication. Communication is a two-player game. If the bosses can't (or won't) understand the basic technical aspects of the software, you have a Big Problem™. If the code you've written is so poorly documented and described that the bosses can't understand it, you have a Big Problem™.

Refine Practices

I am now attempting to describe a process of designing a process intent on producing better processes. It's rabbit holes all the way down. But here is the best advice I have found:

1. Constantly adjust, observe, re-orient, and re-adjust yourself
2. Observe others; are they achieving things by doing something "stupid" or "crazy" or "obviously wrong" that "makes no sense"? They probably aren't stupid or crazy or wrong... go back to point one and give it a try.

Some Examples

Testing

• No Tests - not writing any tests at all encourages a certain type of codebase to develop. Either you know what I mean or you are blessed to not know yet.
• Test Everything Last - at least we're writing tests now. Writing last though encourages the lazier developers (aka me) or the pushier product owners to skip some thoroughness in the test suite. Often leading to missing or broken tests.
• Refactor-Green-Green - tests are written intermingled with code writing. But often written post-code, meaning the writer never sees them fail. Intermingling leaves less chance for missing tests, but does not help much with broken tests.
• Red-Green-Refactor - a minimum set of tests are added, then a minimum code change is made to make all tests pass, then optionally the code is re-arranged into a more readable format. Tests written in this way often have good coverage and are fairly healthy. Tests can become disorganized though.
• Test Everything First - write them all; write them now. Tests have good coverage and are fairly healthy; also well organized. Testing this way has the drawback of being "waterfall-y", if something is discovered late in the process to be incorrect a huge amount of time is wasted re-writing tests.

Release Cycles

• Months Between Releases - leads to a lot of formal processes, reviews, approvals, and change management. An incorrect feature release can be devastating, so rather than ship incomplete features, years are wasted waiting (and it needs to be redone anyway because the business has changed by the time it is released).
• Weekly Releases - time spent meeting cut drastically. Smaller portions of features are released. Changes are manageable and users don't mind waiting for next week for their request. Still some process to review ensuring a week won't be wasted.
• Daily Releases - almost no manual process around releases. "Planning" becomes a loose guideline as changes are requested and executed daily.
• Continuous (or near-continuous) Releases - manual processes nearly evaporate. All the time spent on them are re-invested in the actual building of software. Bug fixes are released within hours. Fear of making mistakes is gone because the consequences of mistakes are nearly gone.

Team Organization

• Technical Area - back-end, front-end, database, etc. common technical concerns (e.g. poor DB performance, UI components) are easily dealt with but every new feature must go through multiple teams increasing cost and complexity.
• Business Area - invoicing-team, marketing-team, etc. new features have a clear, single owner cutting their development costs but cross cutting concerns fall into a "tragedy of the commons".

Explaining Stock Options with a Couch

ISOs, ICOs, IPOs... all the financial TLAs (Three Letter Acronyms) get confusing to anyone who has not worked in finance or done trading. I know I didn't understand.

I'm here to try to explain the main concepts with a couch. Specifically my friend's couch. I'll phone my friend, Xavier:

Me: Hey, Xavier! Heard you're gettin' a new couch, could I have your old one? Xavier: Sure, ten bucks and it's yours. Come over anytime after Friday. Me: Thanks X!

Now, I don't have a couch. I have the option to get a couch. That option has a price: $10 ("strike price" in stock speak). And Xavier isn't a couch store; my option has a limit: 1 couch. I also can't just get the couch whenever I want; I must wait until after Friday to get the couch ("vesting" schedule in stock speak).

So on Saturday, I drive over to Xavier's with $10 in hand and get the couch (in stock speak, "exercise"; and moving couches definitely counts as exercise 😅). Now the couch is probably worth more than $10. If I didn't want the couch, just some cash from selling, I could bring someone willing to pay $100; once we get there, they pay Xavier the $10 I owe and pay me the remaining $90, instant cash!

Do not forget the government has a word for "instant cash": income. And they will be taxing me accordingly. There are ways to lower those taxes. Generally buying the couch early and waiting a long time before selling may subject me to capital gains taxes instead of normal income taxes, which are lower. But there's also a lot of particulars over the specific type of options I have (incentivized or not), what the price is when I get it vs when I sell it vs the actual price I paid, when all those things happened, etc. Probably best to ask a Tax expert or Accountant who can run the numbers in your particular case instead of a random article online talking about couches...

But let's go back to the exercise of getting the couch. What if the couch is actually worth $5? Nothing says I have to buy Xavier's couch. He may be a nice guy, but I'll go get the same couch for half price. Unless Xavier put an expiration date on my option, I can always come back for the agreed $10 if these couches suddenly become collectors items and sell for $500 a piece.

Summary

And that's it. Substitute "couch" with "stock" to get an explanation of stock options.

• Couch: It's... a couch
• Couch option: Not a couch; just an offer to buy a couch at a certain price (regardless of the actual value of said couch)
• Vesting: The predetermined time in the future when the couch can be purchased (after Friday in my story)
• Exercising: Buying said Couch offered in the Couch option (aka turning that Couch option into an actual Couch)
• Strike price: The price to buy the Couch from the Couch option ($10 in my story)
• Fair Market Value (FMV): How much the Couch is currently actually worth to other people ($100 in my story)

A Warning

Couches aren't a good investment strategy. Neither are stock options or equity in a start-up.

It may be possible your options turn in to thousands or millions just like it may be possible the couch you got off your friend turns into a collectors' item. Enjoy it when it happens; Don't depend on it. Don't listen to the person who won the lottery telling you to invest all your cash in lotto tickets. Don't accept equity in return for lower pay and benefits.

You probably are not sitting on a nest egg. You are probably just sitting on a dirty old couch.

Keep It Simple, Stupid

Okay, no need to insult me. I get it! I'll keep my designs simple...

I'm not usually one to call things "problematic", but I do think the way we talk affects the way we think. There's no need to have a put down in one of our best pieces of advice. We're already struggling enough under our own imposter syndromes 😅.

Keep It Stupid Simple

A simple transposition (stupidly simple even 😏) changes our message from insulting to doubling down on itself.

Keep our designs simple (Don't confuse simple with easy. Not just simple: stupidly simple! So simple we can explain them to our non-tech friends and coworkers. Simple enough that our new hire can work on the system within the week (without breaking it on misunderstandings).

Let's re-acronym KISS from Keep It Simple, Stupid to Keep It Stupid Simple.

That's It

Agree? Disagree? Made up problem? I love hearing your thoughts in the comments!

I've already given it away with the cover photo; but why not look at it top-to-bottom instead of left-to-right 😅 (and I will talk about each part in more detail)

Simplest Mental Model of a Server

A server is this: software that starts upon request, runs using the information in the request and data from longer term storage without further input, completing execution by updating the stored data and returning a response.

This model eradicates three main misconceptions:

1. No processing or execution after the response
2. No processing or execution before the request
3. No interrupting or user interaction during the process

The above three things can only be achieved using the "storage" aspect in the diagram to coordinate something else to achieve it. The better we understand that something else is a completely separate process, the better prepared we are to handle the hazards in those patterns. The only way to do any of the above three things is with "storage".

What is "Storage"?

I'm using this as a stand-in for any non-volatile data store.

Most commonly a relational database. But it may also be a document database, key-value store, even an in-memory store like Redis* or just files on the local hard drive. In large or needy applications, more than one may be used, but we can mentally lump them all together into "storage".

This current state gets put in the top and updates come out the other side (if anything needs to update).

* Memory stores are usually considered "volatile" in comparison to hard drives, but to the length of an average request-response, a store like Redis comparably keeps data for eons.

The Request

The first big half of the "request-response lifecycle". Nothing, I repeat nothing, happens in HTTP without a request to start it.

A request can have all sorts of information, but the highlights are:

1. Verb - aka GET, POST, PUT, PATCH, DELETE, etc. each has a meaning; please use them appropriately
2. Host - like www.buymeacoffee.com
3. Path - the slashy bits, like /kallmanation; but also contains the raw query parameters like ?via=kallmanation
4. Various Headers - all sorts of meta-data about the request, mostly look these up as needed; but one is worth mentioning here:
5. Cookies - the thing we always have to "accept"; just a bunch of little pieces of text the requester keeps track of for the server
6. Body - not on all requests; usually JSON, but can be any text for the server to use

Without data in either the storage or somewhere in this request (mainly in cookies), the server can not know about it and in its opinion that information does not exist and has never existed.

The Response

The end of the "request-response lifecycle". Truly, The End, Finito. Nothing happens in HTTP after the response has been returned.

Like requests, responses have all sorts of information, but the big parts are:

1. Status - 200 for OK, 401 for unauthorized, 418 I'm a teapot, etc.; please use the appropriate status
2. Headers - again all sorts of meta-data, look up as needed
3. Cookies - a specific header can tell the requester to send the given cookie with any future requests (they can also be set by JavaScript)
4. Body - HTML/CSS/JS/JSON/XML/etc./etc. whatever we want to send back

Nuanced Mental Model of a Server

To be slightly more pedantic and technical: an application server does not exactly have the entire database stuffed into it on each request. Instead some pre-processing needs to use the request information to formulate a query to storage to load only the needed data.

This "Query" might be a regular old SQL query. But it might be just finding the right file on disk by name and path. Or it could be a request to a separate web service managing storage (like in a Database-as-a-Service). Once the data is fetched, the rest of the server continues as it did in the simpler mental model.

To get even more technical; I've never seen a server application written in such distinct steps of fetch all data, process data, update data, return response. The fetching, processing, and updating usually muddles all together (sometimes rightly, oftentimes wrongly). But still, from an external perspective, a requester could not perceive a real difference between that technicality and the more controlled mental model diagrammed above. So I believe it to be a very useful model of an application server.

I won't beat the dead horse of how unsustainably enterprise depends on open source software. Maintainers treated like indentured servants. Projects abandoned. Dependencies overtaken by malicious actors. Burn-out. It's ugly. Financial support is too Zipf-y. We need a change.

I Do Not Know What I am Talking About

I have not really contributed to open source. My income has always come from an employer. I have not felt the pressure of maintaining a project for other people. I have not tried any other methods to "sustainably" source software. I do not know what I am talking about. I am sure this idea has a multitude of problems and unintended consequences. Please discuss below.

You should just leave now. This "article" is being written to future me so I do not forget. Thank you; have a nice day.

Proposing an Idea Anyway

I am inspired by the Professional Engineer groups in the US, the guilds and apprenticeships of yore, and a system of Universal Basic Income.

And so, the general aspects of this proposal are this:

1. Only professional* software developers have membership
2. Much** software produced by the organization is open to all members but closed to non-members
3. Members may use said software for any purpose the organization approves of (even for profit or for an employer's profit)
4. Members gain shares in the organization only by the promotion votes of other members (these cannot be purchased and non-members cannot hold shares)
5. Shares pay weekly dividends based on organization income from licensing software and membership dues
6. Membership dues are based on individual income (outside of share dividends)

* Professional, here, used in the sense of professionalism not just being paid for a job. ** Members are still free to create fully open source software or closed source software. The organization simply provides a third option of exclusive source software.

Intended Effects

By paying weekly dividends to members, those focusing on the exclusive source software for everyone else are guaranteed a minimum level of financial support, regardless of how "important" or "useful" the contributions. It also provides an instant safety net to developers suddenly losing their jobs or those between jobs (giving all members a boost to negotiation power; able to leave at any time with less consequence).

By allowing increased shareholding only through the voting of peers, the domination by those already financially well-off should be averted. This should provide a mechanism to promote and increase the compensation of those most deserving and contributing to the organization as a whole. There may need to be mechanisms to avoid extremely popular developers from being voted an undue number of shares, simply because of their celebrity status.

The exclusivity means that exploitation of completely open source can be reduced as utilization becomes limited to people and organizations actively paying back in contributions or dollars (if not both). It should also reduce low quality "contribution" to sources as only members (assumably qualified developers) participate.

How Do Members Get In?

For people already developing high-quality software, there should be a nomination and approval process by a minimum number of members.

But for those looking to become developers, there should be an apprenticeship / developer-in-training status for them to learn over time. Apprenticeship in various forms has been proven to work extremely well in grooming skilled workers with practical (not just theoretical) competence.

But those rules leads the question: How does the first "minimum number" of members, become members? Just decreeing myself a member of an exclusive "professional software developers" club seems self-serving, egotistical, and generally unhelpful. There are also legal questions around how "shares" of such an organization would be regulated and how the software would actually be licensed and the licenses enforced etc...

Comments, Concerns, Certainties, and Conversations

Bring it on! My flimsily published idea deserves the fiery furnace of healthy debate. Be kind and courteous. Source facts. Attack ideas not people. Thank you for your time!

$ mkdir new-project
$ cd new-project

In a GUI we would be stuck; but in the command line, we can make this one command instead of two!

Let's make a little function called mcd (for make and change directory). First we need to make the directory:

mcd() { mkdir "$@" }

The "$@" refers to all the arguments given to mcd when it is used. At this point, we've basically made a round about alias for mkdir. So how about adding the cd part now?

mcd() { mkdir "$@" && cd "$@" }

And this kind of works. The problem is mkdir can receive a whole bunch of flags and even multiple directories to create at once, but cd really only expects one argument, the directory to move into. The good thing about how these commands are structured is mkdir expects the last argument to be a directory, which makes it easy for us to pick out the one directory that was created (or if many were created, pick out the last one created) using "$_", which refers to the last argument of the previously executed command.

mcd() { mkdir "$@" && cd "$_" }

And we could be done here, but I added one more thing. If mkdir prints errors, they will all be written in terms of mkdir. But that makes little sense to someone who just ran a command called mcd. I fixed that with sed and some redirection:

mcd() { mkdir "$@" 2> >(sed s/mkdir/mcd/ 1>&2) && cd "$_"; }

For more examples of how this is used, check out my gist.

Disclaimer: this post should be considered humorous and not a comprehensive guide on submitting a good code sample. While it is based on my experience interviewing at Root, it does not reflect the company's opinions or stances on how it conducts interviews; these opinions are solely my own.

1. Include bugs

Do not bother validating that your code sample gives the correct output.

In fact, the more bugs the better! If you show your reviewer that you cannot write bug-free code in a small task you efficiently convince them that you will write bug-riddled code when they hire you.

Letting your reviewer see your lack of attention now lets you get rejected at the code sample instead of at the last interview round (or worse, being hired and then fired later for poor performance).

And the best way to make sure you have plenty of bugs?

2. Do not write tests

Tests are a waste of time. You have a lot of code samples to shotgun out to employers; absolutely do not do any quality control. And more tests will make it harder to include bugs, which was step number one!

If you must write a test; do not make it useful. Make it pass even when multiple lines of the function are deleted. And whatever you do: do not write an end-to-end or integration test; those things take the most time (even more waste!) and find even the subtlest bugs in your code. Just don't do it.

3. Do not include instructions to build & run the code

Remember, you want this sample rejected. If the reviewer cannot run your sample (or can only run after hours of trial and error) they will need to review the code even more carefully.

If you have successfully executed steps one and two, that careful combing of your code will give you the maximum chance of rejection.

Definitely use undocumented dependencies. Even better, depend on something inherent to only your computer (the absolute path to a particular file for instance). Do not use a package manager if it can be avoided (or if you do use it in a non-standard way or use private packages).

P.S. Root has cranked up its hiring machine for 2021. If you would like to practice these 3 steps, go ahead and apply