Whenever you start programming, you’re likely to find that amazing high of building things out of nothing. It doesn’t matter if it’s something simple or complex, usually that feeling will not recede and that’s why I’m here after 10+ years.
However, one thing I struggle with everyday is the friction of coding something you don’t want to code. When you’re learning, you can leave a tutorial mid-way because you didn’t like it. Maybe the author isn’t explaining it clearly, or maybe it’s not fun, and in the beginning fun is all that matters because fun leads to learning. At work, though, not all problems are going to be interesting. Sometimes they’ll ask you to do something boring and tedious like debugging some scenario that only happens when the stars align, so you’re just trying to reproduce it for hours without coding.
It’s not fun, and you can’t quit in the middle of it. Well, you can, and this is the classic meme “well, it doesn’t happen on my machine” but that’s mediocre. After a while, you come to realize that the less amount of code you use, the better off you are because it’s much simpler to fix when the inevitable issue arises.
And it’s not easy. It’s not easy to write succinct code that’s disposable. It’s not easy to make modular programs that provide a straight path when debugging. However, we should always strive for it.
I’ll leave you with a great quote from the article:
“If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.”
Read the full article: How to write disposable code by tef