Practices Icon

Practices

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

Drew DeVault drewdevault.com

Software developers have stopped caring about reliability

Of all the principles of software engineering which has fallen by the wayside in the modern “move fast and break things” mentality of assholes modern 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:

You must prioritize simplicity. You and I are not smart enough to be clever, so don’t try. As the old saying goes, there are two kinds of programs: those simple enough to obviously have no bugs, and those complicated enough to have no obvious bugs. It is by no means easier to make the simpler kind, in fact, it’s much more difficult. However, the simpler the system is, the easier it is to reason about all of its states and edge cases. You do not need a JavaScript-powered custom textbox widget. YOU DO NOT NEED A JAVASCRIPT-POWERED CUSTOM TEXTBOX WIDGET.

Lucas Fernandes da Costa lucasfcosta.com

How to replace estimations and guesses with a Monte Carlo simulation

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.

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.

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.

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.

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.

0:00 / 0:00