Practices Icon


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

Amila Welihinda

A checklist of things to consider before releasing your project

There’s lots of good advice here, covering: 🎨 Initial Presentation 💰 Value Proposition 💯 Project Quality 👑 Branding ✈️ Onboarding Methods 🧹 Code Conventions and Infrastructure 📣 Spread the Word 🤑 Funding If you read the Spread the Word section closely you’ll notice Amila is following his own advice. 😉

read more


On code elegance

A somewhat #longread on what “elegance” means when it comes to code: I get a gut feeling when something is elegant, and a different gut feeling altogether when something is hacky; I suspect most programmers experience the same. The strongest pattern I’ve found is this: Elegance is about expressing exactly what you mean — no more, no less. Conversely, I could define a hack as something that doesn’t remotely express what you mean, but happens to have a close-enough effect. Eevee goes on to disect some code examples. Thankfully, most of them are from video games. 😅

read more

Craig Kerstiens

Give me back my monolith

It feels like we’re starting to pass the peak of the hype cycle of microservices. It’s no longer multiple times a week we now see a blog post of “How I migrated my monolith to 150 services”. Now I often hear a bit more of the counter: “I don’t hate my monolith, I just care that things stay performant” What follows is an excellent rundown of all the advantages that a monolith has over microservices. For a real-world case study, listen to the details of Segment’s transition back to a monorepo.

read more


Would you still pick Elixir in 2019?

The dwyl team went “all-in” on Elixir back in 2016 and are often asked if they would make the same choice again. Here’s the TLDR of their answer: The question of “Which Programming Language” is one we ask ourselves fairly regularly, and is the reason that lead us to discover and decide on using Elixir in 2016. We periodically survey the “up-and-coming” languages like Kotlin, Julia, Lua, etc. and keep concluding that our choice of Elixir is the one we would make again right now. Elixir is the “full package” from idea to deployment! Click through for their full reasoning, which includes why they switched from Node.js to Elixir in the first place, Elixir’s pros/cons they’ve learned along the way, and a list of other languages they would choose given different use cases.

read more

Max Böck

On simplicity

What are your thoughts on simplicity as a feature? Max Böck has this say… I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it. For example… Static sites are on the rise again now, precisely because they are simple. They don’t try to manage server-side code with clever abstractions - they don’t have any. They don’t try to prevent security breaches with advanced firewalls - they get rid of the database entirely.

read more

Nick Janetakis

80 characters per line is a standard worth sticking to even today

Nick Janetakis takes on the most common argument against 80 chars per line: It’s easy to think “wtf, I have a massive monitor, why should I limit myself to a standard that was created for punch cards in 1928 or terminals from the late 1970s?” If that’s what you’re thinking, definitely give this a read. He makes a strong case. One thing is for sure, you don’t want to end up like this guy… 😆

read more

Sam Soffes

Sam Soffes and his static Jekyll blog

Sam Soffes Jekyll’s a little differently. This iteration is built on top of Jekyll, a static site generator written in Ruby. Since I write my posts differently than Jekyll expects, I had to write several plugins to make things work correctly. You might wonder why I don’t just write my posts the way Jekyll wants instead of doing all of this work. I want to keep the details of my blogging engine separate from my content. I’d love to hear from you about your blogging stack in the discussion below. Like Sam, I’m also using Jekyll hosted on Netlify, but I’m new to his plugins.

read more

Max Stoiber

Why I write CSS in JavaScript

You might be on the fence with CSS-in-JS — especially after hearing from Rich Harris about Svelte on The Changelog #332. Max Stoiber writing on his personal blog with his take on the matter: Primarily, CSS-in-JS boosts my confidence. I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too. No more append-only stylesheets!

read more

Yegor Bugayenko

What if the architect is wrong?

Yegor Bugayenko: As you most probably know, I advocate for a dictatorship role of a software architect. All decisions are made by the architect must be final and non-disputable. However, the obvious question is: What happens if the architect is wrong? Does it mean the entire project is at risk of failure? And isn’t it better to make the whole team responsible for the result, instead of having one single point of failure? On the other hand, if the architect happens to be Will Ferrell…

read more

Medium Icon Medium

Kubernetes development workflow for macOS (tips and tricks)

Megan O’Keefe, developer relations engineer at Google, shares her setup for Kubernetes as well as some very helpful tips and tricks from her Terminal setup, navigating clusters, and how she gave kubectl superpowers. As a developer relations engineer for Kubernetes, I work a lot with demo code, samples, and sandbox clusters. This can get interesting to keep track of (read: total chaos). So in this post I’ll show some of the tools that make my Kubernetes life a lot better. This environment can work no matter what flavor of Kubernetes you’re running.

read more

Russ Cox

Houston, we have a software dependency problem

Dig in as Russ Cox goes deep on our software dependency problem. For decades, discussion of software reuse was far more common than actual software reuse. Today, the situation is reversed: developers reuse software written by others every day, in the form of software dependencies, and the situation goes mostly unexamined. … Software dependencies carry with them serious risks that are too often overlooked. The shift to easy, fine-grained software reuse has happened so quickly that we do not yet understand the best practices for choosing and using dependencies effectively, or even for deciding when they are appropriate and when not. My purpose in writing this article is to raise awareness of the risks and encourage more investigation of solutions.

read more

Nikita Sobolev

Best engineering practices: how to fix a bug?

This is a great article that covers the 🐛 gamut: spotting bugs reporting bugs reproducing bugs fixing bugs I love the “lifehack” snippets Nikita sprinkles in as well. Like this little gem right here: Lifehack: sometimes you might want to submit a broken code to your branch so it will trigger a CI build. After the build, it will be saved in your project. And your colleagues will be able to link to this problem. Your next commit will have to solve the issue.

read more

Aaron Turner Medium

WebAssembly vs. ES6 — benchmark battle!

Aaron Turner (UXE at Google) says “WebAssembly is fast” and has conducted a real-world benchmark between WebAssembly and ES6 to showcase Wasm’s performance on different browsers, devices, and cores. …this benchmark will be utilizing the WasmBoy benchmarking tool (source code). The benchmark features three different cores as of today. AssemblyScript (WebAssembly built with the AssemblyScript compiler), JavaScript (ESNext output by the TypeScript compiler), and the previous JavaScript core except run through Google’s Closure Compiler…

read more

Charity Majors

How much should my observability stack cost?

I love the way Charity Majors, CEO of, opens up this post… What should one pay for observability? How much observability is enough? How much is too much, or is there such a thing? Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well? It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”. (Hey, I said almost.)

read more


How simplabs maintains a large number of open source projects

In this blog post we will introduce you to some of out internal best practices we have developed or discovered to simplify and speed up working on open-source and other projects. There’s nothing revolutionary in here for those experienced in open source maintenance, but it’s a good rundown nonetheless. It’s also interesting to see how many teams are now using (and recommending) dependency update services such as dependabot and Greenkeeper.

read more

Yegor Bugayenko

You can do better

Yegor Bugayenko: Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier team player, even though that’s also important. But a more successful software engineer, both financially and socially. Of the 14 recommendations, I’m happy to report that I regularly engage in 10 of them! The only one that I’m diametrically opposed to is Earn Certificates. No thanks! What do you think of Yegor’s recommendations?

read more

 Itamar Turner-Trauring

Enthusiasts vs. Pragmatists

Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer. Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love. Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build. Which is your camp and why?

read more

Eugen Kiss

Lean testing or why unit tests are worse than you think

This is a spectacularly thoughtful and insightful piece by Eugen Kiss on testing: Different kinds of tests have different costs and benefits. You have finite resources to distribute into testing. You want to get the most out of your tests, so use the most economic testing approach. He goes on to describe why he believes that integration tests provide better ROI than unit tests and end-to-end tests. Then he turns his aim on unit tests in particular: There is the claim that making your code unit-testable will improve its quality. Many arguments and some empirical evidence in favor of that claim exist so I will put light on the other side… Unit tests ossify the internal structure of the code. Click through to read his whole argument, but I will say in my experience unit tests only ossify the structure when I do them poorly. In other words, the better I get at unit testing, the more useful they become. In light of that, Eugen’s big takeaway at the end might be 💯 on point: If you desire clear, albeit unnuanced, instructions, here is what you should do: Use a typed language. Focus on integration and end-to-end tests. Use unit tests only where they make sense (e.g. pure algorithmic code with complex corner cases). Be economic. Be lean.

read more

0:00 / 0:00