Mihai on the value of automating as many of your project’s Quality Gates as possible.

For instance, in my projects, I have rules ranging from cosmetic matters like naming or indentation to architectural rules such as “Classes are either abstract or final” or “All variables, of any kind, should be final”.

Dan Abramov on the dangers of doing DRY wrong:

Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.

First you have to learn the rule of writing software. Then you have to learn how and when to let go of the rules.

KBall, Divya, Mikeal, and Feross dig deep into refactoring. When to do it, best practices, things to watch out for, and the difference between a refactor and a rewrite. We then close out with some key pro tips.

If you’re processing large amounts of data in memory, copying data uses up RAM, but mutating data leads to bugs. Learn the design pattern that gives you safety while still reducing memory usage: interior mutability.

Mat, Carmen, and Jon are joined by Dan Scales to talk about Mat’s favorite keyword in Go - defer. Where did the defer statement come from? What problems can it solve? How has it shaped how we write Go code? How are other languages solving similar problems? And what exactly was changed in Go 1.14 to improve the performance of defer?

Lots of good advice in this quick post on Thoughtbot’s blog. I especially like this:

It’s easy to list all the things you think need changing in the pull-request but gloss over all the good things present. If you see something good, say something good! It’s refreshing to receive positive feedback. I find that even simple things like these can go a long way:

• “I love this method extraction”
• “These tests look great! 🎉”
• “Nice catch on this poorly named method! Thanks for changing it”

Guests are catching the bug, so we decided to spend this episode talking about bugs! How do you find and fix your bugs? Do you sketch things out, whip out the debugger, or something else?

Many of the API design opinions found on the web are academic discussions revolving around subjective interpretations of fuzzy standards as opposed to what makes sense in the real world. My goal with this post is to describe best practices for a pragmatic API designed for today’s web applications. I make no attempt to satisfy a standard if it doesn’t feel right. To help guide the decision making process, I’ve written down some requirements that the API must strive for…

Sooo much good advice in this article. Take this golden nugget, for example:

An API is a developer’s UI - just like any UI, it’s important to ensure the user’s experience is thought out carefully!

Yes! This reminds me of the conversation Mat Ryer and I had on Backstage a few weeks back about designing a Changelog API and how I might go about doing that.

Jerod and Divya welcome npm CTO Ahmad Nassri to discuss modular architecture. What it is, why it matters, and how you can achieve it. Ahmad has been thinking deeply about this topic lately and we have a very fruitful discussion that should have takeaways for developers of all experience levels.

If you listened to our GitHub Sponsors episode, you know how much I love sweating the details on a name. I’m not the only one. In this insightful post, Chris Bowler shares some of his struggles with the matter:

When working on a new idea, the hardest part for me is figuring out a name and how to talk about the idea overall. Even when the idea is solid and there is interest or demand for it, even when I can articulate the problem it will solve, I often struggle to find a name.

He then gives five exercises he goes through when picking a name, which I heartily endorse (even though I don’t practice all five).

Manuel Vila, writing for freeCodeCamp:

In this article, I introduce the concept of “unified architecture” that dramatically simplifies the development of full-stack applications.

Indeed, this architecture unifies the six physical layers (data access, backend model, API server, API client, frontend model, and user interface) usually seen in “well-designed” applications into one single logical layer.

It is like going from a 3D world to a 2D world. Everything gets a lot easier.

That “unified architecture” manifests itself as Liaison, which we linked to last week and it caused some… controversy discussion. In this article, Manuel explains why Liaison is different than similar RPC things that came before it. Interesting stuff, to say the least.

When you add anything with user-generated content or dynamic data to a static site, the complexity of the build process can become comparable to launching a monolithic CMS. How can we add rich content to static sites without stitching together multiple third-party services?

Every time I get into the nitty gritty of JAMStack implementations with anything but static content sites I end up saying (or merely thinking to myself), “This sounds like a whole lot of work to avoid some server-side rendering…”

This piece on CSS Tricks appears to back up that premonition:

Despite my enthusiasm, I’m often disheartened by the steep complexity curve I typically encounter about halfway through a JAMstack project. Normally the first few weeks are incredibly liberating. It’s easy to get started, there is good visible progress, everything feels lean and fast. Over time, as more features are added, the build steps become more complex, multiple APIs are added, and suddenly everything feels slow. In other words, the development experience begins to suffer.

The good news is there are many smart, talented folks working on solving the various challenges that JAMStack sites face.

In an effort to make my team write better SQL, I went over reports written by non-developers and code reviews, and gathered common mistakes and missed optimization opportunities in SQL.

Dividing integers, accidentally counting nullable columns, column position in GROUP BY and ORDER BY, and 9 other common gotchas. Don’t get got!

The new issue of Increment is out and it’s all about team dynamics. This piece by Liz Fong-Jones is 🔥

Effective teams write less software, and writing less software enables teams to be more effective. This may sound counterintuitive at first: Aren’t we all here as engineers to write software? Isn’t our productivity measured in lines of code? To dispel this illusion, we need to stop conflating what we sometimes do with why.

How do you know if your Kubernetes cluster is production-ready?

If you’re a beginner, it’s hard to tell what you’re missing. The subject is soo vast and it’s easy to lose sight on what’s the right path to production.

And even if you’re an expert, remembering all networking, storage, cluster, and application development best practices is impossible. There are so many.

Here is a curated a list of best practices for Kubernetes that helps you drive your roadmap to production.

Check things off the list and keep track as you go. ✅

With 35k+ stars, I might be the last one to the party on this awesome repo.

It is the largest compilation, and it is growing every week - currently, more than 80 best practices, style guides, and architectural tips are presented. New issues and pull requests are created every day to keep this live book updated. We’d love to see you contributing here, whether that is fixing code mistakes, helping with translations, or suggesting brilliant new ideas.

I’ve never heard of this method before, but it’s definitely interesting enough to link up for you:

At its core, the MoSCoW method is simply a prioritization framework that can be applied to any kind of situation or project, but it works best when a large number of tasks need to be ruthlessly whittled down into a prioritised and achievable to-do list.

The general idea is you take a list of tasks/stories/whatevs and place each into one of for buckets: Must, Should, Could, and Won’t. (Somehow this gets shortened to MoSCoW for the namesake.)

If you listened to our recent episode on Agile, you know I’m not a fan of ceremony when it comes to planning practices, but I do think there is some value here if you do it right. Click through for the skinny on how to run a MoSCoW exercise as well as some pitfalls to avoid.

German Velasco:

I find that many people confuse refactoring with any change in code. Sometimes they even use the word to mean huge changes that break the application — “we need a month to refactor this monolith.” I think that in those cases, we are misusing the word refactoring, robbing it of its proper meaning, and ultimately, robbing ourselves of the power to communicate an important concept.

Let’s revisit what refactoring is and what it is not.

Some folks might consider this post semantic pedantry, but I think there’s value in knowing the difference between refactoring and merely changing stuff. Don’t get me wrong, I misuse the term on the regular, but when I’m being more diligent with my word choice I will reach for rejiggering instead.

When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:

“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”

These comments imply that JSON is the “one true file format” that should be used for everything, but we don’t believe there’s such a thing. Each format makes tradeoffs in encoding, flexibility, and expressiveness to best suit a specific use case.

The author makes a pretty solid argument that JSON is better for lists, while XML is better for trees.

Robert C. Martin, aka Uncle Bob, joined the show to talk about the practices of Agile. Bob has written a series of books in order to pass down the wisdom he’s gained over his 50 year software career — books like Clean Architecture, Clean Code, The Clean Coder, The Software Craftsman, and finally Clean Agile — which is the focus of today’s discussion. We cover the origins of his “Uncle Bob” nickname, the Agile Manifesto, why Agile is best suited for developing software, how it applies today, communication patterns for teams, co-location vs distributed, and more importantly Bob shares his “why” for writing this book.

Jane Lytvynenko went digging through the Equifax class-action suit and uncovered some absolute gems:

Furthermore, Equifax employed the username “admin” and the password “admin” to protect a portal used to manage credit disputes, a password that “is a surefire way to get hacked.” This portal contained a vast trove of personal information.

Hanlon’s razor often applies in security breaches like these, but I can’t see this as anything but pure negligence by Equifax’s technical teams. There’s more:

Equifax also failed to encrypt sensitive data in its custody… admitted that sensitive personal information relating to hundreds of millions of Americans was not encrypted… Not only was this information unencrypted, but it was also accessible through a public-facing, widely used website.

Filed under you-gotta-be-freakin-kiddin-me

Jon Thornton writes on the Squarespace Engineering blog:

“Tech debt” is a dirty word in the software engineering world. It’s often said with an air of regret; a past mistake that will eventually need to be atoned for with refactoring.

Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! …

The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage?

We also talked about tech debt in a similar manner on Founders Talk #60.

Go Time panelist Jon Calhoun ruminates on a conversation started on episode 94 of the show:

The goal of this article is it explore why exactly there isn’t a single app structure that is recommended to new Gophers, and the overall goal of this series is help newcomers to Go understand what choices are available to them so they can get started a little easier.

When talking about “bad code” people almost certainly mean “complex code” among other popular problems. The thing about complexity is that it comes out of nowhere. One day you start your fairly simple project, the other day you find it in ruins. And no one knows how and when did it happen.

This is a deep-dive into where complexity comes from and finishes with some great advice on fighting it off.

Yegor Bugayenko:

Only weak managers need daily stand-up meetings to coordinate the team, while strong ones use more formal instruments to organize the flow of information. However, as someone noted, morning meetings are not supposed to be used by managers to coordinate anyone, but “to discuss progress, impediments and to plan.” I’m not buying it.

We had a lively discussion on this very topic on yesterday’s recording of The Changelog. Stay tuned for that episode coming next week. 📻