Practices Icon

Practices

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

Gustav Westling westling.dev

Introducing the extremely linear git history

An interesting idea from Gustav Westling…

One of the things that I like to do in my projects, is to make the git history as linear as possible.

Usually this means to rebase commits onto the main branch, but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project.

Today I’m taking this one step further, and I’m introducing a new concept: extremely linear git history.

With our extremely linear history, the first commit in a repo hash a hash that starts with 0000000, the second commit is 0000001, the third is 0000002, and so on!

How he accomplishes this is perhaps even more interesting (and hacky!)

Introducing the extremely linear git history

Chris Klug fearofoblivion.com

Build the modular monolith first

Might a “modular monolith” be the happy middle ground in the endless monolith or microservices decision? You may have to answer that question for yourself, but this post shares some good thoughts around designing a modular monolith:

When designing a modular monolith, it is all about breaking up the system into modules, and then combining those modules into a monolith for deployment.

It might be worth noting that finding what modules you will need, might not be as easy as you would think. They have to be as independent as possible. High-cohesion and low coupling is very important here, as all communication between the modules might end up being a cross network call, if you decide to break it into services in the future.

This means that all communication between modules need to well abstracted, and be either asynchronous, so that they can handle the call going across the network in the future, or use some form of messaging.

Practices simonwillison.net

The Perfect Commit

Simon Willison describes the Perfect Commit as a single commit that contains all of the following:

  • The implementation: a single, focused change
  • Tests that demonstrate the implementation works
  • Updated documentation reflecting the change
  • A link to an issue thread providing further context

Here’s four paragraphs on how he got to here:

I went through a several year phase of writing essays in my commit messages, trying to capture as much of the background context and thinking as possible.

My commit messages grew a lot shorter when I started bundling the updated documentation in the commit—since often much of the material I’d previously included in the commit message was now in that documentation instead.

As I extended my practice of writing issue threads, I found that they were a better place for most of this context than the commit messages themselves. They supported embedded media, were more discoverable and I could continue to extend them even after the commit had landed.

Today many of my commit messages are a single line summary and a link to an issue!

Cedric Chin commoncog.com

Focus is saying no to good ideas

This is one of those pieces of advice that is easy to say, but hard to do. Cedric Chin:

The only problem with this advice is that it’s trite — it sounds obvious; people don’t take it seriously; it’s a cliché. But it really isn’t any of those things, not if you’re actually trying to put it to practice. One of the more interesting things about focus is that you can see it in good operators, if you know how to look. But it happens to also be really difficult to do.

Instead of articulating a fully-fleshed out theory of focus, I want to do something different here. I’m going to tell you a handful of stories. This should do more to illustrate the nature of focus in business than anything else that I can say. Let’s get started.

Some good stories follow. I’ll just add that good ideas is just one category of things that focus means saying “no” to. Another major category is good opportunities.

When you’re first getting started in your career, you are short on opportunities and long on time. But success breeds success. At a certain point, that relationship flips and you have more opportunities (actual, good ones) than you have time. Saying “no” to the wrong ones and “yes” to the right ones is another lesson in and of itself, but the same thing is in danger: your focus.

Jenni Nadler Medium (via Scribe)

When life gives you lemons, write better error messages

This is an excellent deep-dive on error message best practices by Jenni Nadler from Wix:

Error messages are part of our daily lives online. Every time a server is down or we don’t have internet, or we forget to add some info in a form, we get an error message. “Something went wrong” is the classic. But what went wrong? What happened? And, most importantly, how can I fix it?

When life gives you lemons, write better error messages

Vitaly Friedman Smashing Magazine

Rethinking authentication UX

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.

Zed Shaw learnjsthehardway.com

Stripe is Paypal circa 2010

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.

Browser London Icon Browser London

Why user stories belong in the garbage

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 jvns.ca

Some ways to get better at debugging

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.

Practices endtimes.dev

Why your website should be under 14kB in size

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.

Startups blog.southparkcommons.com

Move fast or die

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.

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.

  0:00 / 0:00