Polina Gurtovaya:

Start taking graphics on the web seriously and boost your applications’ performance by learning the essentials about image formats, both modern and old-school. Dig into SVGs and adopt the latest and greatest tools to optimize your graphical content: both vector and raster. Study the theory behind digital images and how humans perceive them—to improve the experience for your users.

Writing good tests is hard, and very few people have thought about this domain more than Kent Beck. In this post, he lays out a short list of properties that good tests have.

Look at the last test you wrote. Which properties does it have? Which does it lack? Is that the tradeoff you want to make?

You should have a plan to roll back releases that aren’t fit for production. In Kubernetes, rolling updates are the default strategy to release software.

In a nutshell, you deploy a newer version of your app and Kubernetes makes sure that the rollout happens without disrupting the live traffic. However, even if you use techniques such as Rolling updates, there’s still risk that your application doesn’t work the way you expect it at the end of the deployment.

Kubernetes has a built-in mechanism for rollbacks. Learn how it works in this article.

Keavy McMinn:

The management path isn’t the only way to be a technical leader. I don’t wish to become a manager; I tried it briefly (73 days to be exact, I counted) and decided managing other people wasn’t where my passion lies. I like being an engineer. In particular, I flourish in a strategic technical leadership role.

This used to be hard to accomplish. It still is, but it used to be, too. 😏

Hopefully we see more engineers like Keavy thriving without having to make the switch to management. Writing about it, talking about it, and showing success stories is a good start towards that end.

Turns out one of our asset caching best practices (content hashes in filenames + far-future expiry) has a serious flaws in it:

In practice, changes to one of your source files almost always invalidates more than one of your output files—and this happens because you’ve added revision hashes to your filenames.

Philip goes on to explain why this happens and then proposes 3 possible solutions. Good stuff 👌

Did you know QWERTY was created in 1878?! I didn’t until I read this interesting piece by Yaron Wittenstein about how he found a new keyboard layout called Colemak that is much less RSI-inducing than QWERTY.

QWERTY typing never felt elegant for me. If always felt like something just isn’t right. Typing is supposed to be fun, and with Colemak it’s much more fun. The motivation wasn’t to type faster than QWERTY but to make typing more fun and less effortless.

Mat is joined by Peter Bourgon, Kat Zień, and Ben Johnson to talk about application design in Go — principles, trade-offs, common mistakes, patterns, and the things you should consider when it comes to application design.

Have you ever created a Kubernetes cluster and wondered what type of worker nodes you should use? For example, if you’re on AWS, should you use many small and cheap t2.micro instances, or some few powerful m5.xlarge instances?

This article discusses the pros and cons of using different worker node sizes in your cluster.

Eric told us a little bit about this idea on this year’s OSCON episode, and I’m so glad he took the time to write it up. Conference organizers: steal this idea!

At Write the Docs, we’re working to make the community easier to join because we want everyone to feel welcome. We do this with the Welcome Wagon program, which helps attendees at both the planning and the attending stages of the conference. We hope that this breaks down barriers to help them get the most value from our community.

When people see me use these shortcuts, they often ask me, “What did you do there!?” There’s minimal effort or intelligence required, but to really learn them, I recommend using one each day for a week, then moving to the next one. It’s worth taking your time to get them under your fingers, as the time you save will be significant in the long run.

Good advice on how to adopt these. Habit formation requires persistence.

In this post, Rich Archbold touches on something we discussed on a recent episode of The Changelog. Specifically, in the episode, we talked about contentment being the enemy of progress and how that might effect our industry psychologically — at-large. But when is what we’re working on ever good enough?

Rich has this to say…

Software can never be perfect, it can only ever be “good enough”…beyond a certain size and rate of change — it’s always going to contain bugs and experience outages. So how do you know if your software is good enough? … My opinion and approach is to codify your beliefs around what constitutes software that is “good enough” into a small set of engineering principles and build a culture, organization, and set of processes that reinforce them.

Donald Knuth famously said:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

You’ve either a) learned this lesson the hard way, b) learned it the easy way (by listening to others’ tales of woe), or you c) should learn it now alongside Victor Zhou as he recounts how he ignored Knuth and wasted a lot of time because of it.

Dave Kaplan (Head of Software Engineering at Policygenius) joined the show to talk about Generative Engineering Cultures and how they have become the goal of industry-aware tech teams. We talk through the topology of organizational cultures ranging from pathological, to bureaucratic, to generative, the importance of management buy-in (from the top down) on leading a generative culture, the ability to contribute original value which is deeply rooted in the concept of aligned autonomy. We also covered the 6 core skills required for us to be empowered in our teams.

A brief discussion of the most essential SEO tags followed by framework-based SEO considerations.

I think all ORM users have a journey from ‘there should be a way to’ to ‘this is saving me so much work’ to ‘I have to reach into the vending machine to get my change out’.

I see the value in ORMs, but I also see where Abe is coming from in this article. I think the sweet spot for an ORM is when you’re just getting started making apps and you want to minimize how many technologies you need to learn to get there. I certainly learned SQL over a slow, productive period while utilizing its features from the warm embrace of Active Record.

Stick around to the end of the article where he reveals the anti-ORM he’s working on to solve some of these problems.

Silas Reinagel:

The difference between great code and terrible code is how well structured the problem solution is. This article gives a clear-as-day way to visualize how well structured code is, in addition to explaining the concepts that result in those shapes.

I’ve long used the squint test as a first step toward evaluating a piece of code. This lines up with what Silas is preaching in this solid piece on software composition.

Yaron Wittenstein:

The world of software is constantly changing at a very fast pace. Yesterday’s axioms might be tomorrow’s anti-patterns.

Newborn technologies rise to popularity only to become obsolete sooner than expected and hardware advancements make things that were considered science-fiction a few years ago possible.

The only certainty is that we don’t know what the future will bring us.

One mantra in this industry is always-be-learning. A message we don’t communicate well enough, however, is how you also have to be willing to let go of once-useful-but-now-limiting knowledge.

Chris Coyier can’t help but chime in after listening to our recent debate episode of JS Party.

I enjoyed all the stumbling around the terminology of “web apps” and “web sites” (web things!). This is such a weird one. It’s so easy to picture the difference in your head: it’s like facebook versus a blog! But when you start trying to define it exactly, it gets really murky really quickly and the distinction loses any value, if it had any to start with. Here’s more on that.

Chris has a lot of great insights here. Whether you agree or disagree, I think we can all get on board with one thing: we make web things!

The goal of this repository is to build a comprehensive set of tools and examples that leverage recent advances in NLP algorithms, neural architectures, and distributed machine learning systems. The content is based on our past and potential future engagements with customers as well as collaboration with partners, researchers, and the open source community.

If you’re an app maker, it might seem like your goal is to get to release day. Get the app done, make it available, publish an announcement, and then get back to coding. Let the world do what it’s going to do.

But that’s not going to maximize your chances for a good release. You need to follow through — you need to keep going.

Brent’s list of things you might do in the wake of a big release is worth tucking away for the day after your next one.

The internet is flooded with programming productivity articles. Isn’t writing a new one is kinda unproductive? 😉

Many of these kinds of posts are tool-specific. This one focuses on the principles instead (and still manages to mix in a few cool tools you may have never heard of).

Stephanie Morillo:

Naming things is hard because languages are hard, and no two people have the same exact understanding of the same word. But we have to ascribe names and labels to things all the time…

This post seeks to help readers understand why labeling is so difficult. There’s a bit of linguistics, library science, and information architecture thrown in for good measure, but the point is this: language isn’t static and the same goes for the websites, databases, and other objects we create and build.

Lazarus Lazaridis:

Email communication is not my favorite but since I can’t avoid it, I am trying to compose messages in a way that I think it makes it easier for both me and the recipient:

• to quickly address what is being communicated
• avoid misunderstandings
• save time

There are some really solid tips in this post. I’ll add another one:

If your email contains multiple questions and/or requests*, number them. In my experience this greatly improves the odds that they each get addressed in the reply. When I don’t number them I usually only get the first or last one addressed.

*let’s please stop referring to requests as “asks”, kthxbai

The term ‘responsive web design’ has been a mainstay in the world of digital development for many years. Go to any early-stage client meeting and you’ll almost always get asked to ‘make sure it works on mobile’.

The standard response to this has generally been, ‘don’t worry, we’ll build it responsive’, but is this response out of date?

What, exactly, is mentoring? How does it work? Better yet, how does it work well? In this post Gergely Orosz, Engineering Manager at Uber, shares his perspective and the practices he’s seen work well.

Mentorship has been the best things that’s sped up my growth and others engineers around me. This post discusses mentorship practices that work well engineer-to-engineer. The practices come from my own experience, observations I’ve made people mentoring each other and from conversations I’ve had with half a dozen mentors in my network and on Coding Coach.