Read on Twitter
i get a lot of replies about my post arguing that you need to see code as a sunk cost, not an investment
the one where i argue for preparing to handle the things you get wrong, and iterating
i always love the replies going "Easy to delete code? Just get it right the first time"
the one where i argue for preparing to handle the things you get wrong, and iterating
i always love the replies going "Easy to delete code? Just get it right the first time"
programmers epitomise the "why wash my hands! i don't piss on them!" attitude, and more annoyingly, go on to explain the urinal was badly designed
"why do we have so much technical debt"
i said elsewhere, but the reason is simple: changes to code always happen in the place that's easiest, and then, eventually, you run out of easy to change parts
honestly? i blame management—"Want Feature! No Refactor! Just Feature!"
i said elsewhere, but the reason is simple: changes to code always happen in the place that's easiest, and then, eventually, you run out of easy to change parts
honestly? i blame management—"Want Feature! No Refactor! Just Feature!"
i mean, i also blame programmers too, there's a cultural norm of painting yourself into a corner and assuming it's an unavoidable consequence of home redecoration
consequences? of my actions!? but i follow best practices!
consequences? of my actions!? but i follow best practices!
i also blame the programmers who talk about abstractions as if they're about hiding detail—rather than sharing it—the ones who talk about modularity as if it's about gathering shared features—rather than keeping the dissimilar parts distinct
a healthy system is one with redundancy—that's the real secret to being easy to change, rather than loose coupling—a system with redundancy is one where local change is feasible, well, local change without unintended global effects
even though programmers decry waterfall they still love to imagine "getting it right the first time", building up the foundations then filling in the gaps
rather than a constant exploration of the problem, coding to learn what needs to be done next, being prepared to cut losses
rather than a constant exploration of the problem, coding to learn what needs to be done next, being prepared to cut losses
i think the most telling example of "getting it right the first time" is the near fetishization for code-reuse—do it once, get it right, move on
when in practice, most reusable software is a product, rather than a library—even the reusable libraries are extracted from products
when in practice, most reusable software is a product, rather than a library—even the reusable libraries are extracted from products
code reuse makes maintenance terrifying
a friend's been struggling with game code, desperate to try and reduce the line count, make parts reusable—in the hope it delivers maintainable software
in practice? well, with no redundant parts, every change is now a global change
a friend's been struggling with game code, desperate to try and reduce the line count, make parts reusable—in the hope it delivers maintainable software
in practice? well, with no redundant parts, every change is now a global change
it's not to say that code re-use is a bad thing, again, operating systems are pretty good most of the time
it is to say that we value it above and beyond it's real worth, to the point of ignoring the problems it introduces
it shouldn't be so contentious to say "it depends"
it is to say that we value it above and beyond it's real worth, to the point of ignoring the problems it introduces
it shouldn't be so contentious to say "it depends"
"build a framework with plugins" "carefully design your abstract classes" are all grounded in this idea that our job is to understand what we're doing, and then write code
rather than write code in order to understand what we should be doing
rather than write code in order to understand what we should be doing
you don't get it right first time
well, you could, if you have a deep understanding the consequences of your actions—but that's something you'll only really learn from hindsight, from experience, from debugging
well, you could, if you have a deep understanding the consequences of your actions—but that's something you'll only really learn from hindsight, from experience, from debugging
my post is a mishmash of contradictory advice, arguing to do one thing, then the opposite—i'd hoped this rhetoric device would explain my underlying point, but alas
the point was that good code depends on context, but people look for universal truths to follow in absolute
the point was that good code depends on context, but people look for universal truths to follow in absolute
the nearest i got to an absolute truth was the title "write code that's easy to delete, not easy to extend"
because extensible code requires understanding every use-case, good and bad, and knowing full well how things will turn out several years down the line
it's really hard
because extensible code requires understanding every use-case, good and bad, and knowing full well how things will turn out several years down the line
it's really hard
anyway, i still love it, a whole post of contradictions, littered with irony and written tongue firmly in cheek, arguing for uncertainty
and people quote tweet it with whatever dogmatic approach they follow, because always they get it right the first time, it's easy!
and people quote tweet it with whatever dogmatic approach they follow, because always they get it right the first time, it's easy!
the people who talk about "clean code" with absolute certainty are the ones who've never had to push it into production, debug it from log spelunking, or add a feature that shouldn't have been left out to begin with
two overlapping circles: people who "get it right first time" and people who've never faced a single consequence for their actions
they're not the people you should listen to, but they're usually the ones who promise easy answers, devoid of context
rather than "it depends"
they're not the people you should listen to, but they're usually the ones who promise easy answers, devoid of context
rather than "it depends"
anyway, i really do love it when someone quotes me to argue the opposite, spoken with absolute certainty, and authority
people who "get things right the first time" are people who refuse to learn, refuse to improve
people who "get things right the first time" are people who refuse to learn, refuse to improve
that all said and done, i do know people who got an awful lot of things right the first time around, but like in operations, no-one thanks you for preventing a disaster
that, and those people are so terrified of consequences they still kick themselves over the tiny mistakes
that, and those people are so terrified of consequences they still kick themselves over the tiny mistakes
i guess i should post a link to the thing i'm talking about to wrap up
but, well, if it was good as i'd hoped, maybe people wouldn't miss the big ideas so easily https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
but, well, if it was good as i'd hoped, maybe people wouldn't miss the big ideas so easily https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
i ended up writing a follow on post, just to hammer home on the things i was alluding to
that the well worn adages of programming are not that useful on their own, and can't be applied without understanding how the rest of the code is impacted
heresy https://programmingisterrible.com/post/176657481103/repeat-yourself-do-more-than-one-thing-and
that the well worn adages of programming are not that useful on their own, and can't be applied without understanding how the rest of the code is impacted
heresy https://programmingisterrible.com/post/176657481103/repeat-yourself-do-more-than-one-thing-and
