KBall, Amal, Chris, Divya, Jerod, and Emma discuss 2020: the good, the bad, and the ugly. Then they change direction and discuss their 2021 resolutions and wishes!

Once again, Sahil Lavingia shared proof that we can think differently about the future of work. Sure, not every company should operate the way Gumroad is operating, but there are plenty of insights to be drawn from their experience.

Recently, I pitched the whole company about going full-time, because it felt wrong to grow any larger without full-time staff.

Nobody accepted.

I realized then that I was trying to copy the status quo–to try and fix something that wasn’t broken–so that I could feel better about doing things the “normal” way. But the deal we already had in place was better for what our people prioritize: freedom over growth, sustainability over speed, life over work.

I recently spoke with Sahil on Founders Talk #66 about failing to build a billion-dollar company. I highly recommend that episode.

Predictions are always fun, especially when we can look back and see how wrong we were. Here’s Browser London’s Jay Freestone laying out where he thinks the frontend is going in 2021:

1. React frameworks finally mature
2. We get a glimpse at container queries
3. WASM explodes
4. The monolith makes a come back

There’s the predictions. Click through for the Jay’s reasoning.

Stork is two things. First, it’s an indexer: it indexes your loosely-structured content and creates a file that you can upload to your web server. Second, it’s a JavaScript + WebAssembly frontend for that index file: Stork will hook into an <input> on your web page, download the index you’ve specified, and display the best search results immediately to your user, as they type. The precomputed index and WebAssembly frontend module make the entire Stork engine very good, and very fast.

Mat Ryer hosts our don’t-call-it-jeopardy game show live at GopherCon! Kat Zień, Mark Bates, and L Körbes put their Go knowledge to the test! Can you outwit our intrepid contestants?

Utkarsh Agarwal:

NPM provides an easy way to publish and distribute Node JS packages for both code dependencies as well as global command-line tools. This article demonstrates how it can be used to publish and distribute binaries written in Golang.

Joel Goldberg recently retired after working in the software industry for over four decades. When he left he shared with our team some of the lessons he learned over his career. With his permission, we reshare his wisdom here.

1. Beware of the Curse of Knowledge
2. Focus on the Fundamentals
3. Simplicity
4. Seek First to Understand
5. Beware of Lock-In
6. Be Honest and Acknowledge When You Don’t Fit the Role

45 years of experience boiled down to just a half dozen insights. Staggering and insightful at the same time.

I really appreciate the perspective Jeff shares in this post on what we know of as personal computing and making tools that improve our lives.

Do you remember when computers were fun to explore? Perhaps you’ve always thought computers were fun to explore, but there was a time before the Internet at the dawn of personal computing when people were excited at the potential of computers. Surely, they’ve probably exceeded most of our expectations today, but at the same time … it’s different. Did we get what we hoped for? Do we still get hope from computers now?

Jessica Kerr talking productivity:

What makes a software engineer productive? You can list attributes like experience with the language, scientific mindset, intelligence, focus, a personally crafted IDE setup. Yet, in my experience, far and away the biggest factor is: familiarity with the codebase they’re changing.

This echoes some of our conversation with Jessica last year. She goes on to explain how the purple developer (pictured below) is 10x more productive than the others, not because they are inheritently better than them in some way, but because they are the ones who built the system in the first place.

“Spread the knowledge, spread the productivity.”

jq is a hugely useful tool for anyone dealing with JSON of varying shapes and sizes. If that’s you, but you haven’t given jq a serious try, this is a great little primer on its use and use cases.

Brandon Smith has hit on a nice credo for code authoring, which he’s “stolen” from Michael Pollan’s advice on food: “Eat food. Not too much. Mostly plants.”

Code, like food, has value. I think those of us who write it can (hopefully) agree on that. Some, though, are so afraid of writing/eating too much that they avoid writing/eating what they should.

In the context of programming, I think this translates to an unhealthy fear (again, for some) of duplication. A little bit of duplication - writing something in a way that doesn’t completely maximize conciseness - isn’t the end of the world. Sometimes it’s the best path forward. Sometimes it’s okay to copy-and-modify here and there, especially when you’re still figuring out what your application will end up being.

A Chrome and Firefox extension that mounts your browser tabs as a filesystem on your computer.

This gives you a ton of power, because now you can apply all the existing tools on your computer that already know how to deal with files – terminal commands, scripting languages, point-and-click explorers, etc – and use them to control and communicate with your browser.

Now you don’t need to code up a browser extension from scratch every time you want to do anything. You can write a script that talks to your browser in, like, a melange of Python and bash, and you can save it as a single ordinary file that you can run whenever, and it’s no different from scripting any other part of your computer.

Why do people complain so much about CSS? There’s memes and jokes about CSS… there’s all sorts of tooling for CSS… On our Frontend Feud episode when we asked, “Name something that frontend devs complain about”, CSS was the #3 answer, which was pretty high up the list.

So it seems like it is a thing that people struggle with, complain about etc. I’m just curious, why do you think that is?

Stephanie Morillo on:

1. Contributing to your team’s internal documentation
2. Getting paid to write and work with an editor
3. Improving your code review process
4. Using templates for writing tech specs and reports
5. Prioritizing learning how to write better emails and chat messages

Mikel Evins on REPL-driven programming:

Interactive development with a proper repl-driven environment is the exception. Most programming is done in other ways.

As a consequence, there are a lot of programmers out there who’ve never even heard of it, who have no idea that it exists. My intuition is that some fraction of those programmers would prefer well-supported interactive programming, and would benefit from it, if they just knew what it was.

Maybe if enough programmers are exposed to that style of programming then we’ll begin to see new tools that embrace it.

An epic 5-part series on building HTML forms right.

Forms are arguably the most important parts of any web application. Without forms, we would not have sites like Google, Facebook, Amazon, Reddit, etc. However, the more I browse the web, the more I see poor implementations of forms.

In this series, we will examine the proper steps to creating forms for the web, how to think about the code we write, and considerations to make along the way.

Austin plans on turning this series into a full-blown book this year, so expect more from him in this arena very soon.

Matthew Monahan:

dug is designed to help you check the global status of your DNS records. You can use the built in servers, update them from remote or local sources, specify servers, whatever. It also supports templated output in CSV or JSON for use in monitoring applications or just piping the results around.

It’s the end of 2020 and on this year’s “State of the log” episode Adam and Jerod carry on the tradition of looking back at our favorite moments of the year – we talk through our most popular episodes, our personal favorites and must listen episodes, top posts from Changelog Posts, and what we have in the works for 2021 and beyond.

Braden Hancock joins Chris to discuss Snorkel Flow and the Snorkel open source project. With Flow, users programmatically label, build, and augment training data to drive a radically faster, more flexible, and higher quality end-to-end AI development and deployment process.

Smug automates your tmux workflow. You can create a single configuration file, and smug will create all required windows and panes from it.

This is inspired by tmuxinator, which I’ve been using for years but has gotten a bit flaky on me with recent macOS upgrades. I can highly recommend the overall workflow, and will be giving this a try real soon. 💯