Tag Archives: programming

Clean code is not a goal


Photo by Kevin Ku on Unsplash

Dan Abramov on how he once overnight refactored a piece of WET code written by a colleague, but then got called out for doing so:

My boss invited me for a one-on-one chat where they politely asked me to revert my change. I was aghast. The old code was a mess, and mine was clean!

I begrudginly complied, but it took me years to see they were right.

There’s a fine balance to be found between code that works for the team and code that is clever/abstract/clean. Sometimes it’s better to write cheap code, as that’s not only cheaper to read, but also cheaper to maintain, cheaper to throw away, etc. — Abstractions are good, up to a certain extent.

On Twitter, Dan also said this about // @TODO comments:

/me nods in approval

Goodbye, Clean Code →

On a related note, be sure to also read Kent C. Dodds’ Avoid Hasty Abstractions

Tests and types

Brent has some thoughts on strong and weakly typed programming languages. Starting point: a simple function that needs testing:

rgbToHex(red, green, blue) {
    // …
}

Testing the result the function should return is easy. But what about edge cases?

What happens though if we pass doubles instead of integers? Or numbers outside of the allowed range? What about null? Or strings Or the wrong amount of arguments? Or a combination of the above?

Ah, the starting point for a nice article … (and no, requiring ints is not a bulletproof solution)

Tests and types →

🔥 Be sure to also check out Brent’s podcast Rant With Brent.

Layers of Technical Debt and Complexity

On July 8, 2015 the New York Stock Exchange went down due to a software glitch. Over at Medium, Zeynep Tufekci went into detail on how it comes that software sucks.

Software sucks for many reasons, all of which go deep, are entangled, and expensive to fix.

[…]

LAYERS AND LEGACIES: A lot of software is now old enough to be multi-layered. Airline reservation systems are particularly glitchy since they’ve been around a while. I wouldn’t be surprised if there is some mainframe code from the 1960s still running part of that beast.

[…]

TECHNICAL DEBT: A lot of new code is written very very fast […] Software engineers do what they can, as fast as they can. Essentially, there is a lot of equivalent of “duct-tape” in the code, holding things together. If done right, that code will eventually be fixed, commented and ported to systems built for the right scale — before there is a crisis. How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there’s the temptation for more duct tape. And so on.

Why the Great Glitch of July 8th Should Scare You →

(via)

Falsehoods programmers believe about time and time zones

  • Every day has 24 hours
  • Every day without DST changes is 86400 (60 * 60 * 24) seconds long
  • Every day in UTC is 86400 (60 * 60 * 24) seconds long
  • Week one of a year starts in January every year
  • If I know what time zone someone is in and they just tell me the date and local time, I can always use software to find out what time that is in UTC
  • DST always sets the clock back and forth by exactly one hour
  • Countries that observe DST begin observing DST in the first half of the year and end observing DST in the last half of the year
  • …

Be sure to click through and read a few more falsehoods, along with their explanations.

Falsehoods programmers believe about time and time zones →