Practices Icon

Practices

Development and business practices, methodologies, workflows, etc.
468 Stories
All Topics

Lucas Fernandes da Costa lucasfcosta.com

Why your daily stand-ups don't work and how to fix them

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.

Ops specbranch.com

Use one big server

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…

Databases brandur.org

Soft deletion probably isn't worth 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 philipwalton.com

Performant A/B testing with Cloudflare workers

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 Bjarnason baldurbjarnason.com

I don't care how you web dev; I just need more better web apps

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…”

Kubernetes jeremybrown.tech

Kubernetes is a red flag signalling premature optimisation

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. 😉

Terminal rhodesmill.org

Start all of your commands with a comma

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.

Startups herman.bearblog.dev

The problem is that your users hate MVPs

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…

Practices nolanlawson.com

The collapse of complex software

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.

Testing paperless.blog

Start test names with “should”

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.

Marko Milojevic hindenbug.io

Two techniques for solving unreproducible (random) bugs

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!

Practices wilcosky.com

Smaller is better (the rise, fall, and rise of flat file software)

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 chriskiehl.com

The mindless tyranny of 'what if it changes?' as a software design principle

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

Jerod Santo maintainable.fm

Having to maintain your own cleverness 🎧

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 jamessimone.net

The life & death of software

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.

The Changelog The Changelog #488

Mob programming deep dive

We’re talking with Woody Zuill today about all things Mob Programming. Woody leads Mob Programming workshops, he’s a speaker on agile related topics, and coaches and guides orgs interested in creating an environment where people can do their best work. We talk through it all and we even get some amazing advice from Woody’s dad. We define what Mob Programming is and why it’s so effective. Is it a rigid process or can teams flex to make it work for them? How to introduce mob programming to a team. What kind of groundwork is necessary? And of course, are mob programming’s virtues diminished by remote teams in virtual-only settings?

JavaScript edofic.com

How i fell in love with low-js

Andraž Bajt:

Basic premise is: browsers are great at navigating pages, let’s leverage that by serving users directly with HTML. This already gives you half-decent pages but you can go further and sprinkle on some sugar. A bit of JS. Instead of reinventing the world in JS let’s try to really use what modern browsers provide natively and then push just a bit forward.

Is the pendulum starting to swing away from SPAs/client-side rendering and back toward MPAs/server-side rendering? Will we ever find balance somewhere in the middle?

Practices shekhargulati.com

Factors to consider when architecting systems that uses third-party systems

In this post, I will talk about important factors you should consider when architecting systems that are powered by third-party systems. The factors I detail are:

  1. deployment model
  2. technology coherence
  3. NFRs and SLAs
  4. Infrastructure and hardware needs
  5. API style and documentation
  6. Idempotent APIs
  7. Getting data out of the third party provider
  8. Community
  0:00 / 0:00