If you have a library dependency that your application relies upon, and you’re afraid to (or for whatever reason will not) peek under the covers and grok its source code… you should not be using that piece of software.
Of all the principles of software engineering which has fallen by the wayside in the modern “move fast and break things” mentality of
assholesmodern software developers, reliability is perhaps the most neglected, along with its cousin, robustness. Almost all software that users encounter in $CURRENTYEAR is straight-up broken, and often badly.
A scathing rant by Drew DeVault, but it comes with sage advice on how we move forward from here:
This piece by Lucas F Costa starts off right where I live:
There are many ways of estimating how long a software project will take. All of them are a waste of time.
It then goes on to describe a different way of doing it:
Instead of making “informed” guesses or multiplying estimations by N, we can embrace the randomness and variability involved in writing software and use more suitable statical methods, in this case, stochastic modeling techniques, to devise better forecasts. One of these techniques is the Monte Carlo method, which I’ll use to make projections in the rest of this post.
In this post, I expand upon Michael Nygard’s post Documenting Architecture Decisions. Michael defines architecturally significant decisions as those decisions that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques. I add examples to each of the five decisions categories.
It’s common for me to get excited about a personal project, put a bunch of time into it, and then lose interest. As much as possible, I want these projects to continue working; upkeep isn’t fun. What does designing for minimum maintenance look like?
When most teams complain about poor quality, they usually mean reliability woes; however, quality spans a more extensive spectrum and can mean many things. This post posits a quality hierarchy that identifies the pertinent challenges and helps with making the right tradeoffs.
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:
- The first rule of Kubernetes: start without Kubernetes
- The first rule of goroutines: start without goroutines
- 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.
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.
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.
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
envsubstlets 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…
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.
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.
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. ✅