John D. Cook: I’ve long been impressed by shell one-liners. They seem like magical incantations. Pipe a few terse commands together, et voilà! Out pops the solution to a problem that would seem to require pages of code. Are these one-liners real or mythology? To some extent, they’re both. Below I’ll give a famous real example. Then I’ll argue that even though such examples do occur, they may create unrealistic expectations. I agree with his overall argument, but the good news about the command line is you don’t have to become a wizard to get value out of it. Start small and go from there.

read more

When I first discovered that nine of my tests were failing due to a broken external API, my first thought was, “Man, maybe I should mock out those API calls so my tests don’t fail when the API breaks.” But then I thought about it a little harder… This is why libraries such as VCR are so awesome.

read more

Don’t put off slow tests as an annoyance: do the math on how much time your team is wasting, and then spend a commensurate amount of time speeding it up. A week’s worth of developer time this month will save you a whole lot more over the course of a year.

read more

Almost 6 months ago I have made a decision to move all our frontend projects from Flow to TypeScript. It was a tough battle inside my head. So, I have decided to write it down to help other people to choose the right tool. And not to make my mistakes.

read more

11, 12, and 14 were new to me. Here is a list of 15 Git commands you may not know yet, but hopefully they will help you out on a journey to master this tool.

read more

Nikita Prokopov writes on his personal blog about eight (8) common sense practices to use when hiring software engineers. I’m not an expert in hiring for big companies, but I have extensive experience for small ones and a bit of common sense. If you are in a business of hiring software engineers, big companies’ practices are not your friends. Common sense, fairness, tolerance, real interest, and open-mindedness are.

read more

There’s always new technologies coming out, and learning them in-depth would take an impossible amount of time. But you can most of the benefit, and more efficiently, by focusing on learning just enough about a broad range of tools to know when they’re useful. You know I’ve been preaching breadth-first over depth-first for years now. In this post, Itamar breaks down why that’s a smart strategy for learning new technologies and lays out a few ways you can gain breadth of knowledge. Unfortunately, he omitted one of the best ways of gaining (and maintaining) breadth: listen to podcasts!

read more

A great idea! There’s a bunch of interviews up already and we can expect a new one each week. Get first-hand advice from seasoned experts to become a kick-ass engineering manager

read more

This is a pretty long post from Jon Skeet on storing and converting UTC. For those interested in more of a tldr, the conclusion at the end of the post is “intended to be read in a standalone fashion.” When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say. This blog post is intended to provide a counterpoint to that advice. I’m certainly not saying storing UTC is always the wrong thing to do, but it’s not always the right thing to do either.

read more

When you hard-attach your library to a specific technology or framework, you limit its potential impact. By thinking ahead and putting in a little more effort, your library could benefit orders of magnitudes more people.

read more

DJ hits the “why should I care” question of Spark SQL on the head. It’s a fun dive into a classic query language that has new value when mixed with the DataFrames API.

read more

Rod Johnson: I’m not against YAML, just against abuse of YAML. I want to help prevent people abusing YAML and being cruel to themselves and their coworkers in the process. YAML has bitten me once or twice over the years, but I am not repulsed by it as many folks seem to be. YAML’s strength is as a structured data format. Yes, it has issues. Whitespace is a minefield. Its syntax is surprisingly complex. It has gotchas: “Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway.” But YAML is human readable and supports comments: two key benefits that drive its popularity. If JSON supported comments it may have killed YAML by now. But alas… Rod makes a good defense of the format for certain uses.

read more

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

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

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

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

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

Look at this user story: As a user I want to receive issue webhooks from Gitlab So that I can list all current tasks Seem valid to you? If you can’t see 8 mistakes in it, you need to read this excellent article by Nikita Sobolev.

read more

The new changelog.com setup for 2019 is packed with exciting features that are too good to keep to ourselves. Since the infrastructure code is already public and has been running changelog.com for a few months now, the value that we are sharing is proven to us.

read more

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

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

Consider adding these mechanisms to your services and making them clearly visible and usable in the README. The poor soul having to solve problems late at night will thank you.

read more

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

Stripe Atlas has a wide array of guides to running an internet business that are totally open and free for everyone. This guide is on “scaling engineering organizations” and covers everything from recruiting and hiring, training and on-boarding, to retention. If you haven’t checked this out yet, it’s a 15 minutes or less read.

read more