Smashing Mag’s Vitaly Friedman puts down some of his recent thoughts on authentication flows:

nobody wakes up in the morning hoping to finally identify crosswalks and fire hydrants that day. Yet every day, we prompt users through hoops and loops to sign up and log in, to set a complex enough password or recover one, to find a way to restore access to locked accounts and logged-out sessions.

Of course security matters, yet too often, it gets in the way of usability. As Jared Spool said once, “If a product isn’t usable, it’s also not secure.” That’s when people start using private email accounts and put passwords on stick-it-notes because they forget them. As usual, Jared hits the nail on the head here. So what can we do to improve the authentication UX?

Vitaly lists seven recommendations. Nothing radical here, but solid advice worth thinking through.

A journey from Stripe to Paypal and back to Stripe led Zed Shaw to the conclusion in the headline. And, no, that is not a compliment (in case you weren’t sure).

Zed goes deep on why he feels this way, listing seven serious downsides to using Stripe today. What’s a dev to do? His advice at the end alone is worth the cost of admission:

This is why I advocate to people to be ready to switch payment processing at a moment’s notice. Right now I could flip two options and I’d be back on Paypal. If I was pressed I could probably implement any other payment processor in about a week or a day. The ability to quickly switch payments is your only defense against frozen accounts, fraud, and rogue employees.

This article isn’t arguing against writing user stories, it’s arguing against keeping user stories:

If you put the story in your icebox/backlog/cooler/hat, it’s time for it to go. It’s now duplicate documentation. That story was only there because you were yet to break it down into tasks. Now you have, so you delete it.

I don’t mean tick it off as complete, I mean right-click on it and hit the ‘delete’ button.

Julia Evans shares five things you can do to getting better at debugging, which is a critical skill for everyone in tech! They are:

1. learn the codebase
2. learn the system
3. learn your tools
4. learn strategies
5. get experience

Each thing comes with an explanation and she shares a great quote at the end (from a paper she extracted these things from):

Their findings did not show a significant difference in the strategies employed by the novices and experts. Experts simply formed more correct hypotheses and were more efficient at finding the fault. The authors suspect that this result is due to the difference in the programming experience between novices and experts.

Having a smaller website makes it load faster — that’s not surprising.

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

The reason for this is because of how TCP works, which is nicely explained in the post. But is 14kB even a feasible reality? The author thinks so:

That 14kB includes compression — so it could actually be more like ~50kB of uncompressed data — which is generous. Consider that the Apollo 11 guidance computers only had 72kB of memory.

Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes — you’re probably there.

Most of our audience knows that we operate on the mantra “Slow and steady wins,” and yet there’s lessons to be learned by reading a post adjudicating the need to “Move fast or die.” Let me explain…

There’s a key phrase that sets this post and its lessons apart from us here at Changelog Media — it’s “Here’s how we did it at Facebook.” Clearly, we are not Facebook, so we should not operate on advice that’s focused on Facebook. However, we can learn something.

Of the the five lessons shared, each can be appreciated, but one in particular stands out.

We embraced asking for forgiveness, never for permission.

This, to me, is synonymous with “Hire people smarter than you,” because it assumes everyone can bring something to the table that former wisdom might not. It gives permission to try something new and see if something beautiful comes as a result. That’s a good thing.

Daily stand-ups are a classic example of learned helplessness. We all know they’re useless, but we tell ourselves “that’s just how things are” and do nothing about it.

Lucas provides a set of five symptoms that indicate you’re doing stand-ups wrong and says if your team hits at least three of the five, your stand-ups are useless.

But, instead of just telling you to stop doing them (like I probably would), he provides a bunch of solid advice on how to make them useful again.

A lot of ink is spent on the “monoliths vs. microservices” debate, but the real issue behind this debate is about whether distributed system architecture is worth the developer time and cost overheads. By thinking about the real operational considerations of our systems, we can get some insight into whether we actually need distributed systems for most things.

Scaling up has always been easier than scaling out. It’s amazing what one beefy server can do these days…

How using OpenAPI (previously called Swagger) has led to being able to ship a new service more effectively, by removing the need to write scaffolding, and instead focus on the business logic.

Daniel Sieger:

If you’ve been developing software for a while, you know that code has this natural tendency to turn into a mess. Keeping software simple over time is a challenge that keeps me thinking. My last post left you hanging without much concrete advice. This time I will outline a few high-level strategies to keep software simple.

Ben Congdon explains why he’s enthusiastic about stacked PRs (and how they differ from stacked commits). We discussed many of these benefits in our conversation with the Graphite guys, but that’s just one way of going about the practice. Ben also lists out a few helpers tools for going about it.

This article confirms my biases because I’ve always despised every soft delete implementation I’ve come up with. Most of them have looked something like what the author describes:

the technique has some major downsides. The first is that soft deletion logic bleeds out into all parts of your code. All our selects look something like this:

SELECT *
FROM customer
WHERE id = @id
    AND deleted_at IS NULL;

And forgetting that extra predicate on deleted_at can have dangerous consequences as it accidentally returns data that’s no longer meant to be seen.

ORMs help with this, but not enough. You set it as a default scope and then there’s that one time where you also want the deleted records so you come up with a custom query or dig into your ORM and try to find how to bypass the rule. Yuck!

He goes on to describe other problems as well. Maybe it’s all a big case of YAGNI?

Once again, soft deletion is theoretically a hedge against accidental data loss. As a last argument against it, I’d ask you to consider, realistically, whether undeletion is something that’s ever actually done.

When I worked at Heroku, we used soft deletion.

When I worked at Stripe, we used soft deletion.

At my job right now, we use soft deletion.

As far as I’m aware, never once, in ten plus years, did anyone at any of these places ever actually use soft deletion to undelete something.

Philip Walton:

While most teams I talk to would love to be able to run A/B tests to accurately assess the performance impact of certain changes, the problem is pretty much every popular A/B testing tool on the market has such a negative impact on load performance that they’re essentially unusable for this purpose.

If you’re just trying to determine which of two marketing headlines converts better, then perhaps this performance difference isn’t so bad. But if you’re wanting to run an A/B test to determine whether inlining your CSS in the <head> of your pages will improve your FCP, well, those popular A/B testing tools are just not going to cut it.

He goes on to describe his process for running performant A/B tests on his static site using Cloudflare workers to swap in/out his experiments.

Baldur Bjarnson:

You don’t need to look far on web dev social media to find somebody lecturing everybody and nobody about how you should do web development. Hell, I’ve been guilty of that myself.

You should use this or that framework.

Or, you should not use this or that framework and instead use a cognitive framework like Model-View-Controller with ‘vanilla’ web components.

No, no, no Functional Reactive is where it’s at.

You should be writing code test-first and unit test everything.

Or, you should go light on the unit tests and focus instead on integration tests.

Or, end-to-end tests. Just test the shit out of the actual running app.

Or, you should use this different kind of unit test which doesn’t look anything like that other kind of unit test.

Those aren’t integration tests! This is an integration test! What’s wrong with you?!
You don’t pair program? Wow, your code must suck.

Sound familiar? Unfortunately, you don’t get to be a “famous” social media influencer by posting reasoned, nuanced takes that end with something like: “I dunno, this works for me but it may not for you. It depends…”

Jeremy Brown:

It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn’t use Kubernetes and a bunch of other “cool” things for your product.

This post turns out to be less about Kubernetes and more about premature optimization and doing more with less. Also it’s about Kubernetes. 😉

Brandon Rhodes’s solution to conflicts between his ~/bin scripts and system binaries: the humble comma

I heartily recommend this technique to anyone with their own ~/bin/ directory who wants their command names kept clean, tidy, and completely orthogonal to any commands that the future might bring to your system. The approach has worked for me for something like a decade, so you should find it immensely robust. And, finally, it’s just plain fun.

Building products is a difficult and time-consuming effort. Figuring out what the problems, finding a potential solution to that problem, and then building that solution all take a decent chunk of time and effort. It’s due to this process that the minimum viable product was born. The motivation for building an MVP is still valid. Build something small and easy to test, launch quickly, and pivot or trash it if it doesn’t perform as desired.

There is another, less selfish way.

I read an article by Jason Cohen a few years ago which changed the way I think about product development. Instead of building MVPs, we should be building SLCs. Something Simple, Loveable, and Complete.

I like the thinking behind SLCs. So simple, so loveable, so…

Hat tip to Henry Snopek for linking this up in the #gotimefm channel of Gophers Slack! When it comes to thinking about your projects, Henry says:

I like to use MVP for fast projects, and SLC for “effective” projects…

Yeah, I like that framing too. So simple, so loveable, so…

Kevlin Henney’s keynote from DevTernity is full of wisdom. It’s long, but the top commenter on YouTube is a saint and provided timestamps for us. 🙌

Nolan Lawson:

Anyone who’s worked in the tech industry for long enough, especially at larger organizations, has seen it before. A legacy system exists: it’s big, it’s complex, and no one fully understands how it works. Architects are brought in to “fix” the system. They might wheel out a big whiteboard showing a lot of boxes and arrows pointing at other boxes, and inevitably, their solution is… to add more boxes and arrows. Nobody can subtract from the system; everyone just adds.

Nolan posits the center cannot hold and the current market shift from bull to bear might help bring the collapse of complex software. But it’s never that simple, is it?

One thing working in complexity’s favor, though, is that engineers like complexity. Admit it: as much as we complain about other people’s complexity, we love our own. We love sitting around and dreaming up new architectural diagrams that can comfortably sit inside our own heads – it’s only when these diagrams leave our heads, take shape in the real world, and outgrow the size of any one person’s head that the problems begin.

Victor Engmark thinks we should start test names with “should” for a handful of reasons, here’s a few:

• It removes redundancy, because the function name should already be in the call stack.
• It is falsifiable, a person reviewing the test can decide to which degree the name agrees with the actual test.
• It encourages testing one property of the function per test

I don’t disagree, but I like to take it a step further: Let the “should” be implied by the rest of the test name.

Instead of: should replace children when updating instance

I prefer: replaces children when updating instances

Instead of: should apply discount when total cost exceeds 100 dollars

I prefer: applies discount when total cost exceeds 100 dollars

Most of Victor’s reasons for using “should” still apply with this format, but it’s less verbose and more accurately describes the software working as expected when the tests pass.

Unreproducible issues, although rare, are typical for each project, sooner or later. They can affect different system parts and make us many causes for investigating and fixing them.

In this article, I try to share some of the techniques I have used in such investigations, which gave me great help in such scenarios. I hope they are helpful to you (if you did not use them already). And, if you have techniques of your own, share them!

Billy Wilcosky:

Flat file web software is about having a set up which doesn’t use a “traditional” database. Instead it uses plain text files, other files, and/or maybe something like a json feed to store the data.

In this post, he explains why he thinks flat file web software is on the come up (again):

Flat file software can be powerful. Depending on what you need. And I think with the right developers and brain power behind the movement it can be more scalable and secure. The sky’s the limit. When I hear a developer saying, no, flat file isn’t good because… really all I’m hearing is they don’t want to change the way web software works. Because what I’ve found is most anything is possible.

Here’s a couple of flat file platforms which are incredible. One is a CMS/blog, the other a forum. Yes, a flat file forum.

A somewhat-related categorical question: Does SQLite count?

Chris Kiehl hits his hammer right on the head of this common sentiment in software circles:

Developers from certain languages [Java] have learned to wield this design principle with more power than many others. It’s how we end up with so much stuff in code bases that’s just… there. Existing. Superficially it appears unused, but silently and stoically, we know it protects us from the turbulent future change which lurks ever ahead.

The antithesis of one of my favorite design principles: YAGNI

I had the honor of joining Robby Russell (who you may remember from Oh My Zsh) on his Maintainable podcast for a super-fun discussion on well-maintained software. Here’s how Robby describes it:

Robby has a chat with Jerod Santo, the Managing Editor and Partner of Changelog Media. Jerod helps lead and co-host Changelog’s flagship podcast, The Changelog, and builds all the cool stuff that makes Changelog awesome. Jerod shares his journey from being a typical networking engineer (Infosec) to the experienced programmer that he is today and his programming wisdom from the trenches.

Tune in as he highlights the undeniable importance of automated test suites and code readability, describes the arc of an engineer’s career, and talks about the past experiences that make him lean more towards clarity over cleverness when coding. He also shares some of the things engineers should consider in regard to pulling in third-party code or writing from scratch, and so much more. Enjoy!

Thanks for having me, Robby! 💚

James Simone ponders the relationship between healthy teams and performance in the software world.

Here’s what it comes down to: teams perform well when successes are shared and failures are owned… We don’t celebrate successes enough, and part of that (I think) is caused by the feeling of pressure that comes from working on a project that seems dooomed to fail without meticulous and ever-present attention.

He goes on to delve in to the source(s) of engineering failures, the dangers of “brightsizing”, known predictors for project success, and a bunch of related topics. Lots to ponder here alongside James, who’s seen a lot of software projects live & die during his eight years in the business.