A quick post by Drew DeVault on why he believes software must be robust, reliable, stable, and simple.

Jonas Lundberg:

In order to know that you are progressing you need some yardstick to measure against. The most common case is someone better and more experienced (having done the trip to mastery themselves) telling or showing you what you need to improve or if you are doing great. But what if there are no coaches or obvious roads to mastery?

From there Jonas goes on a deep-dive on why feedback loops are important and how you can acquire them for yourself. Oh, and if you need a feedback loop (and perhaps some cheer leading) on your writing, join the #blogging channel in our Community Slack. We have a small group forming.

A deep dive on how UDP and TCP affect log delivery and what that means for your application’s complexity in delivering logs. This is a follow-up post to the one we linked to awhile back on why their team ended up with a centralized logging solution. That piece was quite popular (and quite good), so you may enjoy this one as well.

How do you ship a product on schedule? One useful mental tool is the You Ain’t Gonna Need It heuristic: leave out all the things that seem nice-to-have, but you have no proof you actually need. And when there’s things you do need, consider the follow-up heuristic: You Don’t Need It Yet.

In which I pick on Jamstack a bit to make a larger point that we still haven’t found that Silver Bullet and we’re not going to so let’s put our thinking caps on, make sound choices, and pick the right tools for each situation.

Mat Ryer makes the case for passive user preferences, which is where you store their last used setting for them without asking and then set it as the default the next time they interact with that part of your app. He then goes on to describe how they accomplish this with Svelte. Good stuff!

If you want to hear more about how they’re using Svelte and Go to build Pace, we did a pair of podcasts on the topic earlier this year.

Daniel Moch shared his thoughts on semantic versioning and how he treats external libraries that violate its inherent contract with developers.

So as not to bury the lede, I’ll get to my point: Semantic Versioning is a meta-API, and maintainers who are cavalier about violating it can’t be trusted to created stable contracts. I’ve lost patience for breaking changes making their way to my code bases without the maintainers incrementing the major version of their projects, especially in language ecosystems where Semantic Versioning is expected, and in such cases I’m going to begin exploring alternative options so I can ban such libraries from my projects—personal and professional—altogether.
…
If you work in a language ecosystem where Semantic Versioning is the de facto norm, where violating it can wreak havoc downstream, then please play nice and follow its dictates. Instead of viewing it as a straight jacket, try to see it as an algorithm to determine what your next release number should be. We should all like algorithms!

There is the classic saying that “Practice makes Perfect”. This is partly true because it’s also that “Practice also makes you Permanent”.

Now usually comes the part saying that we need to do Deliberate Practice consistently for many years. The thing is that there is a multitude of ways to practice deliberately. There is no one size fits all formula applicable to all domains. And of course - people are different.

I’d like this article to focus on a single deliberate practice side - I call it the “Train Your Own Neural Technique” technique.

Ahmad Nassri returns to the party for a deep, nuanced discussion around the thoughts he shared in a recent blog post called Solving Solved Problems. We hear about the common issue Ahmad’s seen at software shops of all sizes, learn the anatomy of the total cost of software ownership, and debate what to build and what to buy.

Andrzej Krzywda:

My goal is to help you improve the design of the if/else based codebases. Yes, that probably means creating new method, extracting new object. It might be a bit OOP. If that’s not your taste and you’re fine with if/else then this may not be for you.

He then goes on to refactor a deeply nested Ruby method by extracting some classes that are responsible for their own behavior. This is perhaps a bit rudimentary to long-time OOP folks, but I see a lot of code out there looking like Andrzej’s example method so there’s plenty of people who would benefit from understanding this concept.

Node.js development began a bit like the Wild West, but over time idioms, anti-patterns, and best practices have emerged. Yoni Goldberg’s Node Best Practices repo on GitHub collects, documents, and explains the best practices for Node developers. On this episode, Yoni joins us to discuss.

Jonas Lundberg:

Hands on tips for learning a new codebase within a short time frame enough to be able to say: “Steve’s legacy ends here. I’ll figure it out.”

This is a great piece filled with actionable details and particulars.

1️⃣ Value contributions to documentation just as much as code contributions
2️⃣ Put documentation and code in the same project repo
3️⃣ Make documentation a requirement for a merge or release milestone
4️⃣ Have a consistent contribution process for code and documentation
5️⃣ Have well-documented processes for contributing to documentation

That’s the TL;DR, but each of these is expanded upon in the article.

Leszek Zalewski:

The impact of COVID-19 is multifaceted. Our infrastructure team observed an exhaustion of our server resource pool for auto scaling due to a drastic traffic increase! Learn how we achieved 2× faster application run with only 1/3 of the servers by tuning auto scaling rules and switching to Puma threads.

John D. Cook:

I don’t recall where I read this, but someone recommended that if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford.

If you follow this strategy, you’ll sometimes waste a little money by buying a cheap tool before buying a good one. But you won’t waste money buying expensive tools that you rarely use. And you won’t waste money by buying a sequence of incrementally better tools until you finally buy a good one.

What follows is an application of that idea to software tools.

You can use this set of guidelines, fork them or make your own - the key here is that you pick a style and stick to it.

This is a great guide, but the 🔑 is definitely in the highlight above. Consistency is tantamount to readability.

Eduards Sizovs:

People rarely talk about it, but in many companies, code review makes developers feel like sh%t. This is a practical guide on how to create a code review process that developers love.

Click through for 8 recommendations from Eduards on making code review an effective, encouraging, and positive activity.

Writing is hard. Technical writing can be even harder. This piece by Sandy Maguire has lots of help in it:

Here’s the biggest thing to keep in mind: your reader doesn’t really care what you have to say. You get maybe four sentences to convince them that your essay is worth their time. If you haven’t made your case by then, you’ve probably lost them to the next tab they binge-opened.

This is a 5-part series about the zero-trust networking paradigm:

1. Encryption Everywhere (linked above)
2. A Primer On Public-Key Cryptography
3. Certificates
4. Certificate Authorities & Chains Of Trust
5. Bootstrapping Trust

The process and thinking described in this series are the direct output of developing the same system for the Ziti open source project.

Dave Kerr joins Jerod to discuss the various laws, theories, principles, and patterns that we developers find useful in our work and life. We unpack Hanlon’s Razor, Gall’s Law, Murphy’s Law, Kernighan’s Law, and too many others to list here.

So you are building a client-side web app for that next big project and wondering: “Which router should I use?”. Here is the thing: you don’t need any, and you will understand why shortly.

Intriguing!

In the process of moving to our ideal logging system, we constantly discussed the pros and cons of different solutions, and each of us defended the requirement close to them or changed the configuration parameters they needed, asked intriguing questions or sent us back to the original set of requirements.

I love write-ups like this one from the trenches where people share their journey to deciding on a particular solution. Every decision has a context and many blog posts gloss over that, resulting in silver bullet-y hand waving. That’s not super useful when trying to make your own decisions. What is super-useful is being able to understand the circumstances in which others made a choice. That way you can decide if your situation is close enough to theirs to make a similar decision… or not.

Is it time to migrate away from cron?

Like cron jobs, systemd timers can trigger events—shell scripts and programs—at specified time intervals, such as once a day, on a specific day of the month (perhaps only if it is a Monday), or every 15 minutes during business hours from 8am to 6pm. Timers can also do some things that cron jobs cannot. For example, a timer can trigger a script or program to run a specific amount of time after an event such as boot, startup, completion of a previous task, or even the previous completion of the service unit called by the timer.

An analysis by Marco Otte-Witte of the typical problems that arise when scoping and planning software projects as well as some techniques to address and overcome them, reducing uncertainty, risk and frustration.

This post is so brief that I’ll just quote it in its entirety for you:

People have been comparing software components to LEGO blocks for a couple decades. We should be able to assemble applications by snapping together modular components, just like LEGOs. There has been progress, but for the most part we haven’t realized the promise LEGO-style software development.

Integrating two software systems is usually more like performing a heart transplant than snapping together LEGO blocks. It can be done—if there’s a close enough match and the people doing it have enough skill—but the pieces don’t fit together trivially. And failure may not be immediately obvious; it may take a while to see signs of rejection.

Just as true today as it was when John wrote it in 2011.