Practices Icon

Practices

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

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

Follow the money

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 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.

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

Opensource.com Icon Opensource.com

Why I use `exa` instead of `ls` on Linux

We’ve linked to exa in the past, but this post may convince you to give it a try by detailing its many virtues.

I believe exa is one of the easiest, most adaptable tools. It helps me track a lot of Git and Maven files. Its color-coding makes it easier for me to search through multiple subdirectories, and it helps me to understand the current xattrs.

0:00 / 0:00