Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
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:
TODO doesn’t mean you actually intend to do something. It’s a marker for the next person that the logic was left unfinished and they shouldn’t be surprised by missing corner cases or strange code structure.
— Dan Abramov (@dan_abramov) January 11, 2020
/me nods in approval
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 int
s is not a bulletproof solution)
🔥 Be sure to also check out Brent’s podcast Rant With Brent.
Classic Programmer Paintings
“Operations and Developers agreeing on Git workflow”
Jacques-Louis David, 1796-1799, Oil on Canvas
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.
Swift Cheat Sheet and Quick Reference
Swift Cheat Sheet and Quick Reference →
Sidenote: I cannot stop laughing at this sentence that made it onto the Apple site introducing Swift.
Swift is the result of the latest research on programming languages.
Namespaces and closures; ORLY?
Typing.io — Typing Practice for Programmers
Practice typing the awkward characters in code. No drills — type through open source code in JavaScript, Ruby, C, C++, Java, PHP, Perl, Haskell, Scala, and more.
Fun to see how much I actually mistype whilst trying to be fast, and how my IDE autocorrects for me 🙂
Head code is all gone!
How familiar 🙂
Coding-Style Conventions
Analyze Github commits to know which convention is popular.
Instead of arguing where to place spaces and where not, just check GitHub to get to know the popular convention. Don’t agree on tabs vs. spaces though. Go #teamtabs!