Alabe Duarte shares his personal exposure with TDD over the years. This includes:

1. why he believes TDD is important
2. the subjectiveness of “good design”
3. when doing TDD doesn’t help

Joel Goldberg recently retired after working in the software industry for over four decades. When he left he shared with our team some of the lessons he learned over his career. With his permission, we reshare his wisdom here.

1. Beware of the Curse of Knowledge
2. Focus on the Fundamentals
3. Simplicity
4. Seek First to Understand
5. Beware of Lock-In
6. Be Honest and Acknowledge When You Don’t Fit the Role

45 years of experience boiled down to just a half dozen insights. Staggering and insightful at the same time.

I really appreciate the perspective Jeff shares in this post on what we know of as personal computing and making tools that improve our lives.

Do you remember when computers were fun to explore? Perhaps you’ve always thought computers were fun to explore, but there was a time before the Internet at the dawn of personal computing when people were excited at the potential of computers. Surely, they’ve probably exceeded most of our expectations today, but at the same time … it’s different. Did we get what we hoped for? Do we still get hope from computers now?

Brandon Smith has hit on a nice credo for code authoring, which he’s “stolen” from Michael Pollan’s advice on food: “Eat food. Not too much. Mostly plants.”

Code, like food, has value. I think those of us who write it can (hopefully) agree on that. Some, though, are so afraid of writing/eating too much that they avoid writing/eating what they should.

In the context of programming, I think this translates to an unhealthy fear (again, for some) of duplication. A little bit of duplication - writing something in a way that doesn’t completely maximize conciseness - isn’t the end of the world. Sometimes it’s the best path forward. Sometimes it’s okay to copy-and-modify here and there, especially when you’re still figuring out what your application will end up being.

Mikel Evins on REPL-driven programming:

Interactive development with a proper repl-driven environment is the exception. Most programming is done in other ways.

As a consequence, there are a lot of programmers out there who’ve never even heard of it, who have no idea that it exists. My intuition is that some fraction of those programmers would prefer well-supported interactive programming, and would benefit from it, if they just knew what it was.

Maybe if enough programmers are exposed to that style of programming then we’ll begin to see new tools that embrace it.

Michael Lynch lays out 13 techniques you can employ to make your code reviewer fall in love with you, all guided by the golden rule: value your reviewer’s time

Ben Kuhn:

Over time, by consistently exploring the guts of anything I’m working with that seems magical, I’ve built up a broad base of knowledge about how various technical systems work. This helps me in tons of different ways. It makes it easier to track down tricky bugs across many layers of the stack. I can learn new languages and libraries quickly by pattern-matching them to what I already know. It gives me better ideas for software designs, by imitating other systems I’ve seen, or by reusing ideas or tools I’ve heard of in a different context. Maybe most importantly, it gives me the confidence that, if I run into a tricky problem, I can learn enough to solve it, instead of feeling like I’m at the mercy of a system too complex to hope to understand.

This is an excellent piece arguing why you should invest in deeply learning things you already know instead of something new and/or shiny.

It’s not shiny or esoteric, but for me, building a detailed mental model of those (and how they compare to alternatives) might be the learning that’s contributed most to my effectiveness as an engineer.

These mundane, highly-specific things are termed “blubs” for reasons you’ll find out in the piece.

A conceptual explanation of two ways to implement a linked list and why Linus Torvalds believes one implementation has good taste:

[…] I don’t want you to understand why it doesn’t have the if statement. But I want you to understand that sometimes you can see a problem in a different way and rewrite it so that a special case goes away and becomes the normal case, and that’s good code

I haven’t considered linked list particulars for a long time (no job interviews lately, I guess 😜), but I found this explanation clear and illuminating. Maybe you will too.

As both a researcher and a programmer, switching between word processors, programming environments and file explorers was a pain. In this blog post, I show how I streamlined this process to where I never have to leave my terminal to write papers in LaTeX and Markdown, run code snippets directly from my scripts to a REPL, and save sessions and layouts so in just a few clicks.

Devon C. Estes:

It’s fairly common for folks who haven’t used mutation testing before to not immediately see the value in the practice. Mutation testing is, after all, still a fairly niche and under-used tool in the average software development team’s toolbox. So today I’m going to show a few specific types of very common problems that mutation testing is great at finding for us, and that are hard or impossible to find with other methods

He goes on to detail the “multiple execution paths on a single line” problem, the “untested side effect” problem, and the “missing pin” problem.

Chris Wellons:

Machine learning is a trendy topic, so naturally it’s often used for inappropriate purposes where a simpler, more efficient, and more reliable solution suffices. The other day I saw an illustrative and fun example of this: Neural Network Cars and Genetic Algorithms. The video demonstrates 2D cars driven by a neural network with weights determined by a generic algorithm. However, the entire scheme can be replaced by a first-degree polynomial without any loss in capability. The machine learning part is overkill.

Yet another example of a meta-trend in software: You might not need $X (where $X is a popular tool or technique that is on the upward side of the hype cycle).

From Microsoft’s TypeScript wiki on GitHub:

There are easy ways to configure TypeScript to ensure faster compilations and editing experiences. The earlier on these practices are adopted, the better. Beyond best-practices, there are some common techniques for investigating slow compilations/editing experiences, some common fixes, and some common ways of helping the TypeScript team investigate the issues as a last resort.

Securing containers is a complex task. The problem space is broad, vendors are on fire, there are tons of checklists and best practices and it’s hard to prioritize solutions. So if you had to implement a container security strategy from where would you start?

Database (de)normalization is a tricky topic. Just because you can store some of your data in Postgres’ JSON data type, that doesn’t mean you should. But how do you decide? That’s what I asked Craig Kersteins on The Changelog a few weeks back. His answer was insightful, to say the least.

Ron Perris from Snyk this checklist of React security best practices to help you and your team find and fix security issues in your React applications. I’ll show you how to automatically test your React code for security-related errors and automatically fix them.

We’re joined by George Neville-Neil, aka Kode Vicious. Writing as Kode Vicious for ACMs Queue magazine, George Neville-Neil has spent the last 15+ years sharing incisive advice and fierce insights for everyone who codes, works with code, or works with coders. These columns have been among the most popular items published in ACMs Queue magazine and it was only a matter of time for a book to emerge from his work. His book, The Kollected Kode Vicious, is a compilation of the most popular items he’s published over the years, plus a few extras you can only find in the book. We cover all the details in this episode.

Henrik Nyh has a seriously simple system for removing code that ensures he doesn’t miss anything.

This is one of those things that seems obvious when you do it, but in my experience, many people do it haphazardly.

Daniel Stenberg:

Every now and then I get questions on how to work with git in a smooth way when developing, bug-fixing or extending curl – or how I do it. After all, I work on open source full time which means I have very frequent interactions with git (and GitHub). Simply put, I work with git all day long. Ordinary days, I issue git commands several hundred times.

I have a very simple approach and way of working with git in curl. This is how it works.

At a previous employer I had a boss who I thought was pretty tough. Not to me, but our users. No matter the request his response was always the same, “No.” Eventually, we implemented around 40% of the requests, but the constant rejection of these requests stuck with me. Now that I lead a team I notice myself using the same mindset. “No” isn’t negative, and it’s not dismissive. “No” is a way of protecting the team, the project, and the users.

Knowing the architecture of an application is like passively knowing a foreign language. When you speak it - it’s awkward. Here’s how you go from passively to actively owning a code-base.

I’ve been in the industry for a while and experienced a lot of the “no-code problems” that affect us, programmers. I’m talking about impostor syndrome, comparing yourself to others, that kind of stuff.

I decided to write (and promote!) this article as a way to share my experience with beginners and help them deal with that kind of stuff.

Marc Beinder is building a podcast hosting web application as a part of his senior project while at Lindenwood University. In this brief Backstage episode, Marc picks Jerod’s brain about how we built our platform and challenges we ran into along the way.

8 common security issues when using Docker and how to avoid them. Here’s a sampler:

Avoid curl bashing

Pulling stuff from internet and piping it into a shell is as bad as it could be. Unfortunately it’s a widespread solution to streamline installations of software.

The risk is the same framed for supply chain attacks and it boils down to trust. If you really have to curl bash, do it right…

To handle complex authorization policies, a system should handle both points of view efficiently and naturally, in this post we’ll show how we aimed to do that when building oso, an open-source policy engine for authorization.

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