Practices Icon

Practices

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

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.

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.

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.

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.

Nat Bennett simplermachines.com

What happens when you pair all day, most days, for years?

There are obvious upsides to pair programming. This post from Nat Bennett shares both the ups and the downs of pairing all day for years…

So I paired all day, most days, for about five years. This had a lot of upsides, far more than I can list here. There’s a standard list of benefits and drawbacks to pairing that you might be familiar with, but the impact of pairing, especially pairing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.

Nat goes on to share when pairing took more than it gave for them.

Pairing requires being vulnerable, to another human being, for hours at a time. Intimacy, both physical and mental. I had to share space, decisions, thought processes, and often feelings with this person. … This never stopped being draining.

Over time, over years, pairing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.

Jonas Lundberg iamjonas.me

The test-plan

The tests are timing out again!”, someone yells. “Alright I’ll bump them”, you instinctively respond. Then you pause and feel uneasy. Is there another way?

In this blog post, I share my growing disconnect with code-coverage and unit-testing. I then detail the method I’ve been using for the greater part of 7 years and how it still allows me to preach at length that being correct is the single most important thing for a developer.

Luca Rossi refactoring.fm

The true meaning of technical debt 💸

This is an excellent article about understanding technical debt:

It is a fact that, over time, all development teams get slowed down by the existing codebase. But why? Is it because maintenance is inevitable? Or because we could do something better in the first place? Or both?

Luca argues that technical debt is introduced as a by-product of disagreement, which itself is a by-product of two phenomena: wrong design, and rapid evolution. Thoughtful stuff. Well worth your time.

Jerod Santo changelog.com/posts

You might as well timestamp it

In my 15+ years of web development, there are very few things I can say are unequivocally a good idea. It almost always does depend.

Storing timestamps instead of booleans, however, is one of those things I can go out on a limb and say it doesn’t really depend all that much. You might as well timestamp it. There are plenty of times in my career when I’ve stored a boolean and later wished I’d had a timestamp. There are zero times when I’ve stored a timestamp and regretted that decision.

Practices ericlathrop.com

Idempotence now prevents pain later

Idempotence is the property of a software that when run 1 or more times, it only has the effect of being run once. I’ll describe a process I’m making at work, and describe the problems that idempotence will help avoid.

This is a nice, simple example (charging dormant customers a monthly fee) of how a slight change to the way you tackle a feature can make it idempotent, which is most definitely something you want your software routines to be.

GitHub blog.arkency.com

Disadvantages of Pull Requests

In this post, Tomas Wróbel lays out 10 potential drawbacks to the typical PR flows:

  1. More long living branches, more merge conflicts
  2. The reviewability of a change decreases with size
  3. Short feedback loop makes programming fun
  4. Reviews tend to be superficial
  5. Merging is blocked by remarks that shouldn’t be blocking
  6. It’s easier to fix than to explain the fix
  7. Developers are slower to adapt the responsibility mindset
  8. PRs discourage continuous refactoring
  9. Negative emotions and outright pathology
  10. How do you switch to branches with migrations
0:00 / 0:00