The Changelog: Software Development, Open Source - Prioritizing tech debt, UI components to copy/paste, learnings from 20 years in software, git-sim & jqjq (News)

Episode Date: January 23, 2023

Max Countryman wrote up a framework for prioritizing tech debt, shadcn builds a copy/paste-able UI component library in public, Justin Etheredge shares 20 things he's learned in his 20 years as a software engineer, Jacob Stopak's git-sim lets you easily visualize git operations without affecting your repo & Mattias Wadman implemented jq in jq.

What up, fellow nerds? My fellow nerds and I will retire to the nerdery with our calculators. I'm Jared, and this is Changelog News for the week of Monday, January 23rd, 2023. Here's a quick shout-out to everyone who joined Changelog++ last week. Thank you to Justin, Tim, another Tim, and Andrew. We truly appreciate your support. Remember, y'all, Changelog News is a labor of love. We don't make a dime on it.

If you get value from these Monday episodes, return some value with a Changelog++ membership. So we finish 18, and he's going to stiff me. And I say, hey, Lama, hey, how about a little something, you know, for the effort. As with everything we do here at ChangeLog, Plus Plus is a work in progress. If you've considered signing up, but something stopped you, we'd love to hear about it. Please email editors at changelog.com and tell us what's up. Okay, let's get into the news.

Max Countryman wrote up a framework for prioritizing tech debt. Remember, not all technical debt is bad. It's a lot like financial debt. Debt that is secured against an asset, especially one with good odds of appreciating, like a house, is much better than debt that is wrapped up in depreciating assets like cars or highly volatile things like cryptocurrencies or startups. One of our favorite episodes of 2020 was with John Thornton from Squarespace talking about what he thinks are three good kinds of tech debt. Here's a moment from that conversation where we compare tech debt somewhat directly to your mortgage. And again, the analogy of buying a house comes back here because why do you take out a loan to buy a house? Because, well, you could afford a

house over 30 years, but you want to live in that house today, right? And so you're willing to pay more for the advantage of living in that house today. And in the case of these features, you're wanting that feature now, you could build it very slowly and have it 30 years from now, right? But the market opportunity is today. So you take on some debt in order to afford yourself that luxury or that advantage.

Yeah, and I think the house analogy can be extended even further because sometimes you can end up building things that you didn't actually need. And those things can have maintenance or operation costs that are much bigger than, you know, a different implementation might have been. And you can almost compare that to, you know, buying too much house, more house than you

can afford. And then you're stuck with all of this, this maintenance over. Reading Max's post, he agrees that tech debt is often a necessary thing, stating, if a growing company isn't taking on some measure of leverage, then it's likely not shipping as fast as it should be. But there comes a time,

and sooner is usually better than later, when you have to pay down the debt you've been accruing. How, then, is the best way to go about it? That's where Max's post focuses most of its efforts. His suggested process includes surveying the debts you have, assigning effective interest rates based on how active or dormant the subsystem is and how much it costs to maintain, then prioritizing paying it down based on those rates, much like you'd pay off high-interest loans before low-interest ones. Finally, Max has this to say about the entire process. Quote,

In the end, the key thing here is to use frameworks like this to remain solvent in terms of our codebase and product workflow. With tools like this, we can avoid bankruptcy, literally and figuratively. I declare bankruptcy! Hey, I just wanted you to know that you can't just say the word bankruptcy and expect anything to happen. I didn't say it, I declared it still.

Question, when's the last time you saw a GitHub repo reach over a thousand stars without any code in it? The only one I could think of is Kelsey Hightower's hilarious no-code repo, which has over 55,000 stars. But Kelsey's repo is just a really good joke. This UI repo by user shaadcn, or maybe shaadcn, I don't know, s-h-a-d-c-n, has a UI repo with over 1,300 seemingly legit stargazers and no UI code in it. What's being promised sounds promising, though. It's not a component library. Instead, it's a set of components that you can copy and paste into your apps. It's being built with Radix UI and Tailwind CSS,

and the author has been posting some impressive-looking screenshots on Twitter as it's being built. What I like about this most, and why I'm featuring it despite its vapor-weariness, is the idea. There's a Go proverb that says, a little copying is better than a little dependency. I found that to be true much of the time, and I have a feeling it's even more true when it comes to UI components than when it comes to most other areas of the stack. Not that this is an entirely new idea. I'm thinking of it a lot like those SVG icons where you can just copy paste the SVG tag into your HTML and you're done.

But doing that for entire UI components is much more ambitious. Now there's supposed to be code in this repo at the end of January, so maybe it's there by the time you're listening to this. I'll be interested to see how this copy paste style works out in practice. Justin Etheridge shared 20 things he's learned in his 20 years as a software engineer, and Changelog Weekly readers were there for it, making Justin's learnings post the most clicked link in yesterday's newsletter. If you're a weekly reader, you already know my three faves from Justin's list.

One, the best code is no code, or code you don't have to maintain. Two, every system eventually sucks. Get over it. And three, your data is the most important part of your system. There are 15 more where that came from. Reader Dwayne Bradley commented to share his favorite. Sometimes you have to stop sharpening the saw and just start cutting s***. Or in Dwayne's words, stop talking about doing something and just do it already.

In an attempt to demystify Git for users of all experience levels, Jacob Stopak got thinking. What if you could easily get a visual picture of how any Git command would impact your local repo without interrupting your dev workflow? Good question. What resulted was called GitSim, a command line tool written in Python that allows Git users to quickly and easily generate images or even video animations, illustrating the impact a Git command will have on the local repo. You can simulate a Git reset, a merge, a rebase, all kinds of stuff.

Install GitSim with Pip and check out the source on github we're trying something new this week and now for something completely different i put out a request on twitter and mastodon this morning for people to link up cool or offbeat projects they're working on or playing with and we're featuring the most offbeat one here on the show. Matthias Wadman tooted at me. Oh, my goodness. His project, JQJQ. It's an implementation of JQ in JQ. And when I say in JQ, I mean it's written in the JQ language.

Yes, JQ, which started life and still is primarily a command line JSON processor is, according to Matias, a very expressive, capable and nice language. Who would have thought? JQJQ is mostly for learning, experimenting and fun Matias was researching how to write decoders directly in JQ for FQ, his Go-based JQalike for binary formats, which ended up involving some syntax tree

rewriting and walking, and the thing just grew from there. That is some weird, wild stuff. We might do this again soon. If you're building something off-beater weird, follow me on Twitter, at Jared Santo, and on Mastodon, at Jared, at ChangeLog..social and hit me up with the links on Monday morning. The weirder, the better. That is the news for now. If you dig the show, share it with a friend

and consider a Changelog++ membership to directly support our work. We'll be back in your ear holes on Friday with a fascinating conversation all about mainframes. Yes, mainframes are still very much a thing, and we talked to a preeminent educator who's teaching COBOL and other mainframe tech today. Like, he's probably in class teaching it right now. Have a great week, and we'll talk to you again on Friday.