Practices Icon

Practices

Development and business practices, methodologies, workflows, etc.
368 Stories
All Topics

Practices eugeneyan.com

The first rule of X: start without X

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?

Shekhar Gulati shekhargulati.com

My software estimation process

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 trishagee.com

Reading code is a skill

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.

InfoQ Icon InfoQ

Technical debt isn't technical: what companies can do to reduce technical debt

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.

Jonas Lundberg iamjonas.me

I don't understand this (yet)

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.

Ship It! Ship It! #17

Docs are not optional

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.

Ship It! Ship It! #16

Optimize for smoothness not speed

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.

JavaScript zjy.cloud

A simple way to build collaborative web apps

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 matt-rickard.com

Reflections on 10,000 hours of programming

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.

Nick Janetakis nickjanetakis.com

Using `envsubst` to merge environment variables into config files

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.

Security wetransfer.com

Migrating millions of users to Auth0 without downtime

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.

Ship It! Ship It! #11

Honeycomb's secret to high-performing teams

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.

Ellen Spertus stackoverflow.blog

Best practices for writing code comments

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.

Ian Miell zwischenzugs.com

If you want to transform IT, start with finance

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! 👍🏻

Medium Icon Medium

How to review code as a junior developer

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 jacobian.org

Software estimation is hard. Do it anyway.

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.

The Changelog The Changelog #447

The foundations of Continuous Delivery

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 🙇‍♂️🙇‍♀️

Practices programmingisterrible.com

Write code that is easy to delete, not easy to extend

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.

Ship It! Ship It! #8

Cloud Native fundamentals

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.

0:00 / 0:00