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:
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
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.
Erik Kennedy with a checklist of his most important UX tips for creating usable signup and login forms. He covers everything from field autofocus to letting people optionally see the password they’re typing. ✅
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.
In this article, I’d like to explore a couple of implementations of sorting algorithms. However, I’d like to do so driven by unit tests. The examples are written in Go, but don’t worry if you never worked with Go before. The emphasis here is on the journey and the joy of building solutions guided by tests!
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.
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?!
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.
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!
When it comes to scaling, we might need to think about:
In this article, I will present some basic ideas and starting points on scaling traditional SQL databases.
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:
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.
Nick Janetakis shares a few patterns he’s picked up based on using Docker since 2014 for many freelance projects. He also posted a timestamped video version on YouTube if you’d prefer to watch over reading.
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.
Brian LeRoux has been building the web long enough to see many ways we produce HTML come in and go out of fashion. On this episode, he joins Amal & Nick to discuss the past, present, and potential future of rendering patterns on the web. SSR, ISR, & DSR (oh my!)
Chris Manson goes into detail about the benefits of a clean git history and describes some tips and tricks that really help you clean up your branches and Pull Requests.
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?
