Eugene Yan, in a post titled The first rule of machine learning: start without machine learning:

Applying machine learning effectively is tricky. You need data. You need a robust pipeline to support your data flows. And most of all, you need high-quality labels. As a result, most of the time, my first iteration doesn’t involve machine learning at all.

Eugene is stating the obvious with this post, but hey sometimes you just gotta state it. What’s even more interesting to me is how nicely the format generalizes! Let’s pattern match this sucker:

The first rule of X: start without X

Now, apply the pattern a few times and see if it holds:

1. The first rule of Kubernetes: start without Kubernetes
2. The first rule of goroutines: start without goroutines
3. The first rule of coding: start without coding

Yeah, that abstraction holds pretty true. Surely there will be cases where it falls flat on its face, though. Can you think of any examples?

In this post, I cover in a step by step manner how to do software estimation for project bids where there is limited clarity and a lot of ambiguity. I cover how we can use an uncertainty factor to cover the unknowns, questions/things to ask/consider at each step of the software estimation process, and some practical advice. This process is based on estimates I have done for multiple projects in the last couple of years.

Trisha Gee writes (because Someone Is Wrong On The Internet):

The problem is not that we shouldn’t write readable code. Of course we should aim to write readable code, if only for our own poor selves further down the line (there is no one less capable of reading my code the following week than me). The problem is that these two issues are not mutually exclusive. It’s not “write readable code” or “learn to read code”. That’s like saying, “I’m going to drive really economically so I don’t need to put petrol in the car”. No. You’re still going to need to put fuel in the car (if it’s not electric!) at some point no matter how economically you drive.

She writes a lot more than just that (of course) and even gave a talk about it, which is also worth digesting.

In this article, three experts discuss some of the key findings of the State of Technical Debt 2021 report including the impact of technical debt on engineering teams, the pros and cons of dealing with maintenance work continuously, the future of technical debt, and what each engineering teams can do to communicate the importance of dealing with technical debt to leadership.

Remember, not all tech debt is bad, but even good tech debt has its ramifications. Solid insights here.

Chris Coyier on some of the new(ish) CSS compilers (such as Assembler) and how they’re flipping the script:

The popular Tailwind framework supports it. It kind of flips the mental model of Tailwind on its head, to me. Rather than providing a huge pile of CSS utility classes to use — then “purging” what is unused — it only creates what it needs to begin with.

Building software is difficult and time consuming, but the maintenance of software is where we spend the majority of our time. In this episode, Ian and sam join Johnny and Kris to discuss how to build actually maintainable software, the features of Go that make it good for writing maintainable software, and different ways that we might define the term “maintenance”.

You gently face-palm and let out a groan. Your bug is so obvious now. How did you miss it before? Thank goodness you didn’t blame Bob publicly.

In this blog post we will look at how to get unstuck with things you do not understand (yet). It’s a methodical approach to solving insight problems - problems where all the information is known but you need to see it a different light to solve it. We start from writing down the problem and move through increasingly more esoteric phases such as changing location to invite insight in.

To build or to buy, that’s a constant question we ask ourselves as software engineers. In this episode we dig into the nuance of these options and the space between them with an eye toward both the building of software and its eventual maintenance.

On this week’s episode, Gerhard is joined by Kathy Korevec, former Senior Director of Product at GitHub, and now Vercel’s Head of Product. Docs play an essential role in GitHub Actions, and Gerhard’s experience has proven that. Building, testing, and shipping code with GitHub Actions works better because of their excellent docs. However, the docs that Kathy pictures are not what you are imagining. She explains it best in her post, Maybe it’s time we re-think docs, which is what started this whole conversation.

The bottom line is, just as you wouldn’t ship untested code, shipping code without documentation is not optional. Today’s conversation with Kathy explains why.

This week Gerhard is joined by Justin Searls, Test Double co-founder and CTO. Also a 🐞 magnet. They talk about how to deal with the pressure of shipping faster, why you should optimize for smoothness not speed, and why focusing on consistency is key. Understanding the real why behind what you do is also important. There’s a lot more to it, as its a nuanced and complex discussion, and well worth your time.

Expect a decade of learnings compressed into one hour, as well as disagreements on some ops and infrastructure topics — all good fun. In the show notes, you will find Gerhard’s favorite conference talks Justin gave a few years back.

This is an excellent post that takes you along on the author’s journey to build a simple, collaborative (desktop-like interactions and realtime collaborations, such as Notion, Discord, Figma, etc.) todo app:

With the help of many great tools, we’ve successfully built a fast, collaborative todo app. More importantly, we’ve worked out a reasonably simple approach to building similar web apps. As the user base and feature set grow, this approach shall scale well in both performance and complexity.

Both the resulting frontend and backend code are open source and you’ll likely learn about some new tools (like Replicache) along the way.

Matt Rickard shares 31 reflections after putting his time 10k hours in programming:

These are reflections only about pure coding — no lessons sum up to “programming is about people” or “how to be a senior technical leader” (arguably more important to a career, but not the topic of this post).

These reflections are just about deliberately writing code for 10,000 hours. Most don’t apply to beginners. These reflections are not career advice. Think of them as lessons on being a technical guitarist, not about being a good band member. They are about becoming a better programmer for yourself.

Here’s the first one, just to whet your whistle:

Browsing the source is almost always faster than finding an answer on StackOverflow.

Fossil deliberately omits a “rebase” command because the original designer of Fossil (and original author of this article) considers rebase to be an anti-pattern to be avoided. This article attempts to explain that point of view.

Read this article by SQLite/Fossil creator Richard Hipp to prep for next week’s episode of The Changelog. 😉

Nick told us about this on our modern Unix tooling episode, but I thought I’d link up his excellent writeup/video on the subject for those who had a hard time following with audio only.

Let’s say you have an nginx or Kubernetes config file which doesn’t support templating out of the box and you want to dynamically create config files based on 1 or more environment variables. This is what envsubst lets you do.

The WeTransfer team recently finished a big migration with the goal achieving Single Sign On (SSO) across their 3 products.

This post goes into the details on why they chose Auth0, how the migration process went, the challenges they faced, and the things they learned along the way. Here’s an example of one of their learnings:

Think about accounts ownerships between products. Is it possible for an attacker to take control of another account with the same email? How do you avoid that? We decided to ask for credentials or require a password reset in those scenarios where we couldn’t guarantee account ownership.

Jessica Kerr, TL;DR’ing herself for you:

When different parts of an organization need to coordinate, it seems like a good idea to help them coordinate smoothly and frequently. Don’t. Help them coordinate less — more explicitly, less often.

I think she may be on to something here…

Gerhard talks with Charity Majors, ops engineer and accidental startup founder at honeycomb.io about high-performing teams, why “15 minutes or bust,” and how we should start using Honeycomb in our own monolithic Phoenix app that runs changelog.com. There is just one step, and it’s actually really simple!

They also talk about how Honeycomb uses Honeycomb to learn about Honeycomb, which is one of Gerhard’s favorite questions. As for key take-aways, deploying straight into production is really important, but not as important as optimising for humans - which are not replaceable cogs, that learn and share their learnings continuously. That is the secret to making things easy and happy for everyone.

This expands on topics that we have discussed in Ship It! #11 and covers community findings on the practices that make the biggest difference for:

• Higher productivity
• Improvement in code quality
• End-user satisfaction
• Software developer retention

Ellen Spertus on Stack Overflow’s blog:

While there are many resources to help programmers write better code—such as books and static analyzers—there are few for writing better comments. While it’s easy to measure the quantity of comments in a program, it’s hard to measure the quality, and the two are not necessarily correlated. A bad comment is worse than no comment at all. Here are some rules to help you achieve a happy medium.

I like rule #6 (provide links to the original source of copied code) and rule #9 (use comments to mark incomplete implementations) in particular.

This is a follow-up blog post to Ship It! #6 Money flows rule everything

• To achieve anything significant you need funding
• To get funding you need to persuade the people with the money to part with it
• To persuade the people with the money, you need to understand what they value
• To understand what they value, you need to understand how their cash flows work
• To understand how their cash flow works, you need to understand
  • your customers/clients and how and why they part with their money
  • the legal and regulatory constraints on your business and how it operates

The rest gets even better. It was great to read your follow-up thoughts, Ian! 👍🏻

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.

Jacob Kaplan-Moss begins where I often do when discussing estimation:

One study by HBR found that one in six IT projects had cost overruns of over 200% and were late by almost 70%. Another study by McKinsey found that IT projects are on average 45% over budget and 7% over schedule. They found large software projects were particularly bad: software projects with budgets over $15M went over budget by an overage of 66% and had schedule overruns averaging 33%.

Nonetheless, there are good reasons to estimate anyhow… and you can get better at it over time.

One major “secret” to advancing in a technical career is learning how to give accurate estimates. It certainly has been for me: I don’t shy away from giving timelines, and I’ve learned how to be right often enough that folks trust my estimates.

If you always avoid estimation and don’t learn how to give a timeline when it’s required, that might become a limiter on your career. Being able to tell your bosses and peers what to expect by when – and then hitting those marks – builds trust in a major way.

If you like this post, maybe follow it up with the one where he covers his technique for estimation.

This week we’re sharing one of the most popular episodes from our new podcast Ship It. Ship It launched in May and now has 8 episodes in the feed to enjoy…it’s hosted by Gerhard Lazu, our SRE here at Changelog.

In this episode, Gerhard talks with Dave Farley, co-author of Continuous Delivery and the inventor of the Deployment Pipeline. Today, most of us ship code the way we do because 25 years ago, Dave cared enough to drive the change that we now call CI/CD. He is one of the great software engineers: opinionated, perseverant & focused since the heydays of the internet. Dave continues inspiring and teaching us all via his newly launched YouTube channel, courses, and recent books. The apprentice finally meets the master 🙇‍♂️🙇‍♀️

Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.

Deleting code is fun! Let’s all write code that’s easy to delete. But how?

To write code that’s easy to delete: repeat yourself to avoid creating dependencies, but don’t repeat yourself to manage them. Layer your code too: build simple-to-use APIs out of simpler-to-implement but clumsy-to-use parts. Split your code: isolate the hard-to-write and the likely-to-change parts from the rest of the code, and each other. Don’t hard code every choice, and maybe allow changing a few at runtime. Don’t try to do all of these things at the same time, and maybe don’t write so much code in the first place.

There’s a lot to think about in that paragraph right there. Thankfully, the author of this piece continues from there, giving specific advice along the way. A must-read, even if you aren’t onboard for all of it.

Why Cloud Native? What are the guiding principles that you should keep in mind as you are choosing a project from the Cloud Native Landscape? How do you build & ship an app in a Cloud Native way? Katie Gamanji, Ecosystem Advocate @ CNCF and former cloud engineer for American Express, Condé Nast and Microsoft, joins Gerhard to cover these topics in the context of the Cloud Native Fundamentals course that she developed. 15,000 students have already enrolled, and the initial feedback has been great. Tune in if you want to know why you should too, how to do it and when the course will become available for free.