Practices Icon

Practices

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

Abdulfatai Popoola abdulapopoola.com

When sleeping dogs bite: Unmaintained systems breed disasters

There is a general belief that legacy systems, stale code, and archaic tooling are sleeping dogs – we avoid them fearing a collapse from interference or deprioritize them for seemingly more important projects. I think this strategy of intentional avoidance and/or deprioritization is perfect for disasters.

The challenge with systems that do not fail is that they have no fixes when they eventually fail. Thus, it is more urgent to fix these systems than is usually accepted.

Cloud rohanrd.xyz

Why you should start self hosting

A short, cogent argument why hosting your own cloud services is worth the time/effort:

Consider this, you carefully curate your playlists on Spotify but every now and then you see a certain song missing from your playlist. Same goes for videos saved in your YouTube playlists or other music/video streaming services. Then there is also the case of OTT streaming platforms where the show you were going to watch over weekend has now disappeared.

The author points to r/selfhosted and this awesome self hosted list as good resources to get started.

Ship It! Ship It! #45

Swiss Quality Assurance

Pia Wiedermayer, Lead QA at Zühlke, is talking with Gerhard today about software quality. If the name sounds familiar, check out episode 28. Thank you Romano for the introduction 👋🏻

Do you remember the last time that you used an app, whether it was in the browser or on your mobile, and everything just worked? What about that intuitive feel, snappiness and you achieving the task that you intended to without feeling that you are fighting tech? Experiences like those take a lot of effort across multiple disciplines. They are designed, built and maintained over long periods of time. It all starts with people like Pia that really care about quality. It’s so much more than just automated testing…

The Changelog The Changelog #483

ONE MORE thing every dev should know

The incomparable Jessica Kerr is back with another grab-bag of amazing topics. We talk about her journey to Honeycomb, devs getting satisfaction from the code they write, why step one for her is “get that new project into production” and step two is observe it, her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design can translate to how we skill up and level up our teams, and so much more.

Jean Yang future.a16z.com

Building for the 99% Developers

Jean Yang:

Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.

As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.

Good stuff to be reminded of. That reminds me: You are not Google/Amazon/LinkedIn.

Chris Ferdinandi gomakethings.com

SPAs were a mistake

Chris Ferdinandi:

For years, a trend in our industry has been to build single-page apps, or SPAs.

With an SPA, the entire site or app lives in a single HTML file. After the initial load, everything about the app is handled with JavaScript. This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps.

Today, I want to explore why that’s nonsense. Let’s dig in!

I built one of the first big SPAs (remember Grooveshark?), but I’ve shied away from them ever since. I do think there are cases when they make sense (Trello and GMail come to mind), but overall I think too many people chose the architecture too many times because it was the it thing to do vs it was actually the best decision for their circumstance.

Heck, even Chris’s disclaimer of ‘when SPAs make sense’ section at the top is easily defeated by our Turbolinks implementation. But I digress… read this post it’s a good one for sure.

Derek Sivers sive.rs

Write plain text files

Derek Sivers:

I write almost everything important in my life: thoughts, plans, notes, diaries, correspondence, code, articles, and entire books.

They are my extended memory — my noted self — my organized thoughts. I refer to them often. I search them, update them, and learn from them. I convert them into HTML to make websites, or LaTeX to make books.

My written words are my most precious asset. They are also a history of my life. That’s why I only use plain text files. They are the most reliable, flexible, and long-lasting option. Here’s why.

Practices rachelbythebay.com

Returning values and errors

If you agree with the notion that you need to be able to tell the difference between the absence of a value and a value itself, then this has some impacts on the code you write. If you want to keep ’em separated (so they can come out and play), then it gets you looking at your API designs in certain ways.

These are my reactions to some of the ways a value can be returned (or not).

Before you head off to read Rachel’s post, allow me to close the loop on that Offspring reference for those of us who didn’t grow up in the 90’s.

The Changelog The Changelog #480

Git your reset on

This week we’re joined by Annie Sexton, UX Engineer at Render, to talk about her blog post titled Git Organized: A Better Git Flow that made the internet explode when she suggested using reset instead of rebase for a better git flow. On this show we talk about the git flow she suggests and why, how this flow works for her when she’s hacking on the Render codebase (and when she uses it), the good and the bad of Git, and we also talked about the cognitive load of Git commits as you work.

Ship It! Ship It! #39

Haunted codebases & complex ops

This week we are talking to Robin Morero, the person behind fabled.se, a DevOps consultancy from Gothenburg, Sweden. Their motto is “move faster and prosper”, which Gerhard prefers to the initial “move fast and break things”.

Fabled works with startups primarily, and after 26 years, Robin has a few interesting insights to share. What do you think, are haunted codebases real? At what point do pull requests become harmful? What about k3s running on KVM as a simple starting point for production? If this reminds you of #7, and the follow-up YouTube stream with Lars, it’s no coincidence.

Troy Hunt troyhunt.com

How I got pwned by my cloud costs

Troy Hunt (of Have I been Pwned fame) has been a vocal proponent of cloud-first services for awhile. Last December, that strategy came back to bite him:

It all started with my monthly Azure bill for December which was way over what it would normally be. It only took a moment to find the problem…

He goes on to tell the tale in excruciating detail. Be careful out there, cloud natives.

Test Double Icon Test Double

Stop paying tech debts, start maintaining code

Jesse O’Brien from Test Double wants us to stop using the term “Tech Debt”

There’s loads of reasons why unmaintainable code ends up running in the systems our products are built on, but none of these fit the definition of debt.

Instead, I propose we drop the term Tech Debt and start talking about maintenance tasks. Maintenance is what we’re really talking about. When parts on our car or bicycle suffers wear from driving them around, we don’t talk to our mechanic about “mechanical debt”. (Go back and re-read that sentence, but replace things with “software” and “programmers”). We talk about maintenance.

This post starts as mostly a semantic debate, and I’m not convinced by his arguments there. I think the debt metaphor is useful when you’re talking about trading quality for speed. That’s what you do when you take on debt: you trade higher cost at a future date (principle + interest) to gain access to the money today (speed).

That being said, I really like where Jesse ends this piece talking about software maintenance and methods of going about it. Lots of actionable advice there and I’m 100% onboard with talking about software maintenance early and often. One of the first things I consider when somebody approaches me with a feature idea is ask myself: what will this cost to maintain?

Git render.com

Git organized: a better git flow

Imagine this: you’ve been paged to investigate a production incident, and after some digging, you identify the commit with the breaking code. You decide to revert the change:

git revert 1a2b3c

Unfortunately, in doing so, a new bug is introduced! As it turns out, hidden in that old “broken” commit was some code that another part of the app depended upon, and when you reverted those lines, it left the site once again in a broken state. 🙃 Oh dear.

How can situations like this be avoided? To answer this question, we first need to examine how these types of commits come to be.

If you’ve never heard of or used git reset… this article is a must-read.

JavaScript blog.jim-nielsen.com

The optional chaining operator, “modern” browsers, and my mom

Any debugging story that includes the phrase, “My Mom’s verbal JIRA ticket was right” has a lot of promise. This one by Jim Nielsen delivers the goods. Here’s the culprit:

In my brain, I always thought of Safari and Chrome as “modern” browsers. But even Chrome, an “evergreen” browser, failed because it wasn‘t on an “evergreen” operating system (or hardware).

and his takeaway:

The real-life impact of our technical decisions really hit home to me once again: my Mom had trouble volunteering and participating in her local community because somebody shipped the optional chaining operator in their production JavaScript.

Be thoughtful out there.

Martin Heinz martinheinz.dev

Profiling and analyzing performance of Python programs

Martin Heinz on the tools/techniques for finding bottlenecks in your Python code. And fixing them, fast.

The first rule of optimization is to not do it. If you really have to though, then optimize where appropriate. Use the above profiling tools to find bottlenecks, so you don’t waste time optimizing some inconsequential piece of code. It’s also useful to create a reproducible benchmark for the piece of code you’re trying to optimize, so that you can measure the actual improvement.

Arnold Galovics arnoldgalovics.com

Don’t start with microservices – monoliths are your friend

Arnold Galovics:

Microservices are getting natural and we almost feel like we’ve been always living in the world of microservices. Lately when I talked to other developers and asked how they would start a greenfield project, almost certainly the answer was, well, one microservice for this, another one for this, another one for user management, one more for authentication, another for authorization, one more for session management, and the list could go on.

I’m gonna try to shed some light on what nobody is talking about when it comes to microservices. And yeah, it’s gonna be a first-hand experience from a past projects I worked on.

This excellent piece gave me some serious deja vu of Kelsey Hightower’s monoliths are the future. I’m quite looking forward to Arnold’s upcoming “chapter 2” of the story.

0:00 / 0:00