Devyn Cairns & Jakub Žádník join Justin & Autumn to talk about building a new kind of cross-platform shell that provides easy extensions with traditional command compatibility. That’s no easy feat!

David Hugh-Jones has a lot to say about what makes a good comment, Hugging Face released a distilled variant of Whisper for speech recognition, The New Stack reports on C++ creator Bjarne Stroustrup’s plan for bringing safety to the language, Jeff Sandberg declares that CSS is fun again & Jose M. Gilgado praises the beauty of finished software.

An open platform for operating LLMs in production, working quickly is more important than it seems, imaginary problems are the root of bad software, Val Town is a social website to write and run code & Aaron Francis’ guide to finishing your projects.

Now that you’ve aced that CFP, the gang is back to share our best tips & tricks to help you give your best conference talk ever.

Will McGugan’s Trogon auto-generates friendly TUIs for your CLI apps, Stability AI’s official open source variant of DreamStudio, John Calhoun writes about life after 26 years programming at Apple, Google’s news TLDs could be a boon to scammers & Pablo Meier documents a way to discuss programming languages.

+10x engineers may be mythical, but -10x engineers exist. To become a -10x engineer, simply waste 400 engineering hours per week. Combine the following strategies:

I know the 10x developer is a myth and all, but one thing we don’t talk about very often is that it is sometimes easy to out-pace other devs simply by moving forward at a decent clip.

This is because there are easy (yet non-obvious) ways to make negative progress as a developer. It’s not hard to move orders of magnitude faster than someone who’s headed in the wrong direction.

Justin Searls dives deep into whether AI tools like ChatGPT actually threaten knowledge worker jobs and provides helpful ideas around what to do about it.

Having spent months programming with GitHub Copilot, weeks talking to ChatGPT, and days searching via Bing Chat as an alternative to Google, the best description I’ve heard of AI’s capabilities is “fluent bullshit.” And after months of seeing friends “cheat” at their day jobs by having ChatGPT do their homework for them, I’ve come to a pretty grim, if obvious, realization:

The more excited someone is by the prospect of AI making their job easier, the more they should be worried.

Yury Molodtsov:

Running your own blog in 2023 is still needlessly complicated, especially if you have any kind of taste. Why have one in the first place?

Social apps and networks are obviously the easiest options, but they’re geared toward vastly different things, and I just don’t trust their longevity. Having your own platform enables flexibility and portability, so your content can be kept online practically forever.

This!

There are many options out there, ranging from WordPress and Ghost to static blogs to managed online platforms and Micro.blog. How do you choose between them?

What follows is a survey of some of the popular tools and what Yury thinks about them. My advice is this: don’t worry too much about tooling. That’s the easy part. Writing’s the hard part. We often bike shed the easy parts to avoid the hard part. Yuri seems to agree:

Having the right tool certainly helps, but at the end of the day, what matters is what you write there. Focus more on the content and just ensure the process of writing and posting is simple enough.

It’s “Call For Papers” (CFP) season in Go land, so we gathered some seriously experienced conference organizers to help YOUR submission be the best ever.

Scott Antipa:

I’m working on a flowchart editor that runs in the browser, and I wanted a way for people to use it without having to sign in, or store any data on our server. I wanted to give them control over their data and to be able to store it locally to open and edit later. And also easily share it with other people. It’s easy to do this by supporting file upload/download, but I wanted something simpler, like the ability to share by sending a url. I also didn’t want to store anything on the backend (at least for the free tier).

What he decided on was to base64 encode the entire application state and store it in the fragment section of the URL. I love all the upsides of this approach and it’s pretty trivial to accomplish. Here’s the pseudocode that Scott provides in his post:

const stateString = JSON.stringify(appState); // appState is a json object
const compressed = compress(stateString);
const encoded = Base64.encode(compressed);
// Push that `encoded` string to the url
// ... Later, on page load or on undo/redo we read the url and
// do the following
const decoded = Base64.decode(encoded); // same encoded as above, but read from url
const uncompressed = uncompress(decoded);
const newState = JSON.parse(uncompressed);
// Now load your application with the newState

We don’t normally include how-tos in Changelog News, but I’m making an exception for this post because a) it goes deep on how Docker works on macOS, and b) this is a problem that plagues so many of us that I thought it worth pointing to a solution.

There’s also a nice bit about Development Containers at the end, which are quite promising, indeed.

Jacob O’Bryant’s “Grand Vision For How Social Media Ought To Be”:

there should be a bunch of different:

• publishing services, like Substack and Ghost
• reading apps, like Gmail and Matter
• community platforms, like Slack and Discord

and we should look for ways to make these reading, publishing, and community services all play nicely together. I’m calling this model “the unbundled web,” and I think RSS should be the primary method of interop.

Where do I sign up? 😉

While obtaining a job internationally may seem daunting, this guide will walk you through all the steps you need to find and secure a developer job abroad.

In this article, I share how how to prepare your resume for getting a developer job abroad, how to search for international opportunities, application strategies, important considerations to make when applying, the do’s and don’ts of successful interviews, and more!

This is awesome — Brandon, please write down more lessons learned, even if they’re just something for you to reference later on.

I’ve been doing this “reliability” stuff for a little while now (~5 years), at companies ranging from about 20 developers to over 2,000. I’ve always cared primarily about the software elements I describe as living “outside” the application – like, how does it get its configuration? What kinds of instances does it run on, and are those the best kinds to use? What steps does it take on its path from “code in a repository” to “running in production”? And I’ve always kept track of what I liked – which mechanisms allowed fast iteration and which caused frustration, which led to outages and which prevented them.

… So! With that out of the way – this is how I’d rebuild it all from scratch if I could.

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.

Robb Owen:

Why let JS have all the fun? With mix-blend-mode finally gaining wide browser-support, we now have access to many of most common shading techniques in CSS. With some choice images and a bit of careful layering it’s possible to build some surprisingly high-quality effects without the need for introducing any JS dependencies.

If you’ve ever used Photoshop’s Blend Modes… you can basically do that in CSS now. So cool! Check out Robb’s entire article. He includes a lot of great examples.

Rob Barnes (a.k.a. Devops Rob) and Rosemary Wang (author of Infrastructure as Code - Patterns & Practices) are joining us today to talk about infrastructure secrets.

What do Rosemary and Rob think about committing encrypted secrets into a repository? How do they suggest that we improve on storing secrets in LastPass? And if we were to choose HashiCorp Vault, what do we need to know?

Thank you Thomas Eckert for the intro. Thank you Nabeel Sulieman (ep. 46) & Kelsey Hightower (ep. 44) for your gentle nudges towards improving our infra secrets management.

Sounds like Jacob Kaplan-Moss isn’t the only hiring manager who’s keen on the reverse code review:

When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice. Because of this, I have found that some methods work better than others to discover talent.

… instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:

The advantages in brief:

1. Reading probes the most fundamental skills
2. Reading code is way more efficient than writing.
3. Reading puts candidates at ease compared to writing code.

Click through for the details and how to put this in to practice.

Here’s one of the 15 language-agnostic, actionable tips on REST API design:

Use conventional HTTP status codes to indicate the success or failure of a request. Don’t use too many, and use the same status codes for the same outcomes across the API.

Smile Egbai had a solid rant about this on Go Time recently.

Julia Evans lays out her process for taking API responses in her browser’s dev tools and using them in her own programs/scripts:

1. look in developer tools for a promising JSON response
2. copy as cURL
3. remove irrelevant headers
4. translate it into Python

Some of you might be wondering – can you always do this?

The answer is sort of yes – browsers aren’t magic! All the information browsers send to your backend is just HTTP requests. So if I copy all of the HTTP headers that my browser is sending, I think there’s literally no way for the backend to tell that the request isn’t sent by my browser and is actually being sent by a random Python program.

The New Stack’s Jennifer Riggins covering Kubecon+CloudNativeCon 2021:

The Cloud Native Computing Foundation has more than 138,000 contributors making over 7 million contributions to more than 100 open source projects. It’s reasonable that getting started in open source would feel overwhelming — to say the least. So how do you get started as a contributor to cloud native projects? How do you find a mentor or guide to help you along?

She draws many solid takeaways from a panel that discussed this exact topic at the event. This quote from Grafana’s Uchechukwu Obasi is spectacular:

“I think open source really changed my life,” Obasi said. “I’m African, I live in Africa, but having the opportunity to work on software that impacts millions of lives, it’s an opportunity that I never take for granted. If open source can change my life, it can change yours too.”

This piece by Lucas F Costa starts off right where I live:

There are many ways of estimating how long a software project will take. All of them are a waste of time.

It then goes on to describe a different way of doing it:

Instead of making “informed” guesses or multiplying estimations by N, we can embrace the randomness and variability involved in writing software and use more suitable statical methods, in this case, stochastic modeling techniques, to devise better forecasts. One of these techniques is the Monte Carlo method, which I’ll use to make projections in the rest of this post.

I’ve never gone full mouseless (nor do I necessarily recommend it), but there’s extreme productivity wins to be mined by keeping your hands on the home row as much as possible.

Building a development environment with the shell as a keystone offers multiple benefits. You can use tools that fit nicely with each other, you can customize everything depending on your own needs, and the biggest of all, you can control your entire development environment with your keyboard. This can save a lot of cognitive energy as well as deliver a pleasant user experience.

This is an excellent walk-through on Smashing Mag for those ready to level up their terminal game:

Today, I’d like to share with you these tools so that you too can increase your efficiency and your comfort in your daily job. They work well together — shaping what I call my Mouseless Development Environment. More precisely, we’ll discuss:

• Why using the Linux shell can be very powerful when working with plain text (including code);
• Why using the dreaded Arch Linux;
• The advantage of a tiling window manager;
• How to have a great terminal experience with URxvt, tmux, and tmuxp;
• Why Vim can become your best friend.

On this episode, we make our big Frontend Feud announcement, welcome Amelia to the party, then share a metric crap ton of productivity tips & tricks: scripting, pomodoro, retaining your dev flow, and more!

The panel are joined by Teiva Harsanyi, author of 100 Go Mistakes, to talk about how best to make mistakes when writing Go.

Emma Catlin writing for Pinterest Engineering:

… at some point in my first year, I realized something critical: I needed to help the entire team, not just myself, in order to grow to the next engineering level. To start, one of my teammates recommended I review code.

The advice was simple enough — use code reviews as a way to learn more about a piece of code and expand my knowledge of our overall system. It turned out code reviews were the perfect way for me to continue my learning journey.

She got better at it over time (of course) and shares some of those learnings in this excellent post.

Chip Huyen has been on both sides of ML-related interviews and has a lot of expertise on the process:

If you’ve picked up this book because you’re interested in working with one of the key emerging technologies of the 2020s but not sure where to start, you’re in the right place. Whether you want to become an ML engineer, a platform engineer, a research scientist, or you want to do ML but don’t yet know the differences among those titles, I hope that this book will give you some useful pointers.

What you will see next is a highly subjective, non-exhaustive unordered list of principles that, if you follow, I can guarantee will lead you to become a bad developer…

If your goal, fellow reader, is to become a good developer instead, don’t worry. Remember that via negativa is way more powerful than via positiva. That means that knowing what not to do is safer and easier to figure out than exactly what to do. So pay attention to the following topics and decide which type of developer you want to be.

I (dis)agree with every thing that Rafael lays out. I’ll add a bad one of my own: Optimize immediately! Because if your code doesn’t run at ludicrous speed, does it even matter if it executes correctly?!

Docker images can leak runtime secrets, build secrets, and even just some secret files you have lying around. Learn how to leak them, and (probably more usefully) how to avoid leaks.

Programmers are taught very early on about the importance of organizing their code. Whether it is naming variables and functions, or naming and organizing files, this is a topic covered early in nearly every programming course.

All of this begs the question: why is it so damn hard to figure out how to structure Go code?