Practices Icon

Practices

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

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.

Ops incident.io

Incidents are for everyone

A perspective on incidents that makes a lot of sense actually, and captures the “Why?” perfectly. My highlights: Incidents involve more people than we think. Tooling just makes it really hard for them to help. We have more incidents than we realise. We just don’t hear about them. Your whole team, on the same team. Practice makes perfect.

Jonas Lundberg iamjonas.me

Getting unstuck

You sigh. Maybe the compilation didn’t work? You recompile and run it again. Nope. Still the same problem. You stare out the window.

This post is about ways of getting unstuck on a problem when you do not (yet) have all the relevant knowledge. It focuses on the problem with the ego when being a more seasoned programmer and the difficulty on admitting that you don’t know (yet).

From there we go through the steps on being unstuck and making that ego more inflated and annoying.

Rafael Quintanilha rafaelquintanilha.com

How to become a bad developer

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?!

Liran Tal github.com

The largest Node.js CLI Apps best practices list ✨

A bad CLI can easily discourage users from interacting with it. Building successful CLIs requires attention to detail and empathy for the user in order to create a good user experience. It is very easy to get wrong.

In this guide I have compiled a list of best practices across areas of focus which aim to optimize for an ideal user experience when interacting with a CLI application.

Ship It! Ship It! #6

Money flows rule everything

This week on Ship It! Gerhard talks with Ian Miell, author of Docker in Practice as well as Learn Git, Bash, and Terraform the Hard Way. They talk about being comfortable with the uncomfortable, focusing on the tech while keeping a holistic view of the business. Following the money flows is key. Ian explains this concept really well, and Gerhard feels fairly confident you will be better off if you pay attention. Let us know in the comments!

Petr Stribny stribny.name

Scaling relational SQL databases

When it comes to scaling, we might need to think about:

  • data storage, if we store more and more data and it becomes expensive or slow working with them
  • fast INSERTs and UPDATES for write-heavy workloads
  • making SELECT queries faster because of their complexity or because they need to query huge amounts of data
  • concurrency if we have many clients interacting with the database

In this article, I will present some basic ideas and starting points on scaling traditional SQL databases.

Ship It! Ship It! #5

The foundations of Continuous Delivery

This week on Ship It! 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 🙇‍♂️🙇‍♀️

Miroslav Nikolov webup.org

Arguments for a project kickoff strategy

Miroslav Nikolov:

You may not be a project manager. Perhaps you are a developer who likes to code and solve technical challenges. The organizational matter is something you care less about. After all, your company is likely relying on some agile methods and there are product owners and/or SCRUM masters to handle the process. You just need to build new features.

While that’s true you have to sometimes get out of your comfort zone.

Ship It! Ship It! #4

OODA for operational excellence

This week on Ship It! Gerhard talks with Ben Ford, former Royal Marine and founder of Commando Development, about the OODA loop (observe, orient, decide, act). Shipping is just a small part of it. The OODA loop that you know is probably the wrong one. We explore Mission & Command, Situational Awareness and a few other practices that will help you deal with complexity as you code and ship. As a former Royal Marine Commando, Ben learned these skills the hard way, and then refined them over many years as a software engineer. Check out the diagrams in the show notes - they are a work of art and precision.

0:00 / 0:00