It's a title of a blog. In my option, I absolutely can debug my code tomorrow which I wrote today. So how to understand that?

  • 14
    Tomorrow? Probably. Next month? Maybe. Next year? "..." ;-) Commented May 6, 2016 at 3:26
  • 6
    Not addressed in the answers, but touched on in the comment by @DamkerngT.: tomorrow in this case means "the future" not "the day after today". Commented May 6, 2016 at 17:27

9 Answers 9


It's a rephrasing of the old programmer's adage: "don't be clever"! Or Brian Kernighan's famous quote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?

Basically it's saying that you shouldn't write clever and/or tricky code because debugging such code later will be very hard.

  • 1
    Yeah, I'm pretty sure this is the intent behind that blog title. The quote is from the days when computers were still not really fast enough, so programmers had a strong tendency to make their programs overly complex and unmaintainable in the name of efficiency.
    – doug65536
    Commented May 6, 2016 at 7:30
  • 22
    @doug65536: They still do... ;-)
    – DevSolar
    Commented May 6, 2016 at 9:38
  • ++bwk (not sure who it's pointing at now) @doug65536 Yes, we have a greater variety of excuses now. Commented May 6, 2016 at 19:02
  • 1
    Or if you are being clever (and sometimes you have to be to get the job done), document just how your bit of cleverness works, so you'll understand it later when you have to debug it. And for @doug65536: in the world of non-trivial programs, faster computers mean you just get to solve bigger problems in the same time.
    – jamesqf
    Commented May 6, 2016 at 19:43
  • @jamesqf: Being clever and being dirty/hacky are two different things. Being hacky is doing something ugly to get the job done. Being clever is over-engineering something because you think it's cool/cute/neat.
    – slebetman
    Commented May 7, 2016 at 3:25

It sounds like the quote means or intends for the developer to write clean and simple code that may be easily understandable even after some period of time .

The code should be easy enough to understand even if viewed after a certain period of time


It's sounds like a play on the phrase "Don't put off until tomorrow what you can do today". It's attributed various people including Benjamin Franklin and Thomas Jefferson.

Essentially it means "don't procrastinate".

If I had to guess, this version is intended to encourage readers to write clean code, particularly if you don't have the time to debug it.

I think that "can't" in this case doesn't mean "if you don't have the ability", it means "if you don't have the time".

So, my interpretation of this title is:

Write clean code today because you may not have time to fix it tomorrow.

  • Estimates vary, but I've seen figures creeping toward 90% of a programmer's time spent debugging. (It would be interesting to know how Stack Overflow has skewed this metric...) Anything you can do to reduce that fraction is very likely to be a net win. On the other hand, writing code that you can't debug later is a huge time sink in terms of time spent fixing the inevitable problems.
    – user
    Commented May 6, 2016 at 7:46
  • 2
    The original phrase is important to understand the intent of the title, so glad someone included it. It's almost certainly unfamiliar to the OP.
    – JPhi1618
    Commented May 6, 2016 at 13:51

Even for simple programs, I remember having hard times understanding some details a few months later. Because I don't not use explicit enough variables, because I did not comment lines that seemed simple back then.

Most often, because I started coding directly, without taking a little time with pencil and paper before to map ideas, to record limitations, to foresee dependencies, to check whether I did a similar program before (which I did forget). Every program, no matter how small and big, is a project, and deserves some project plan, asking at minimum (quoting from the preceding link):

  • Why? - What is the problem or value proposition addressed by the project? Why is it being sponsored?
  • What? - What is the work that will be performed on the project? What are the major products/deliverables?
  • Who? - Who will be involved and what will be their responsibilities within the project? How will they be organized?
  • When? - What is the project timeline and when will particularly meaningful points, referred to as milestones, be complete?

Today and tomorrow should not be taken literally. You would be a different coder in a few month.


Since we're in English Language Learners StackExchange and not in Programmers StackExchange, Tomorrow means in the future in its figurative sense (weeks, months, years later), not literal (in 24 hours).

If you ever studied your first programming language at school (or at home) several years ago, try to find where you stored your old school projects, and read them. When you wrote them you knew exactly what you were doing right? (don't code today...)

Turns out you will probably struggle to understand your own code, and unless you were an experienced developer when you learned your first language (ahem), you had probably not left many hints for your future self to help him/her understand what you were thinking back then (...what you can't debug tomorrow).

In this sense, when you write code you have to keep in mind someone else is going to read it. And that someone else could be a "future you". The "future you" could go from several days, to several weeks, to months or years later.

Ultimately the saying "don't code today what you can't debug tomorrow" or rephrased "aim to write readable and maintainable code in the long-term" is a general rule for developers. You write code for your colleagues to read, and eventually your future replacement once you'll get promoted or move to work for another employer. Seen from a different angle, if you don't write maintainable code, no-one can replace you and you won't get promoted.


It's a phrase that needs to be understand in terms of maintenance, try to put yourself in to those person shoe who have to deal with the code/project of other person.

What I understand is if you can't understand your after some time then it will be very difficult for someone who is working/solving bug of yours.

So use commenting to your code is very necessary to make it clear, what logic you were having in your mind just note it down, so after some in future if you are working on that same code or someone other then it can be easily have workaround with your project.


The quote, you say, is:

don't code today what you can't debug tomorrow

It's not what you seem to have read it as, which would be more like:

no matter what you code today, you won't be able to debug it tomorrow

…which, as you point out, is nonsense.

The real quote is encouraging you not to write code that is difficult to understand. If you would struggle to understand it if you came back to it in a year, that's bad; if you would struggle to understand it if you came back to it in a month's time, that's a big problem. If you wouldn't be able to understand it enough to debug it tomorrow, then something is terribly wrong and you should not have written it that way. (In that sense, there's some hyperbole in there.)


It simply means write a simple code including comments which can be easily debugged in the absence of the developer who is the owner of the code or may be by the developer itself after a period of time.


When coding, remember some other poor soul may have to debug it, who hasn't been privy to your thought processes. And (as Laurent Duval points out) you probably won't remember either. So write clear comments which inform the reader (especially if the mechanics of what you are doing are at all obscure - e.g. subtle but rarely-used features of the programming language). A bug in the code is forgivable - it can, with some effort, be found and corrected. But a bug in the comments, or in the design documentation, will mislead people for ever. But find the right level. I once had to work on some code which resembled going into a forest where every tree had a label "This is a tree" - when what I wanted to know was "This is 'Kings Wood', producing oak for Naval shipbuilding".

  • While this is good programming advice, I'm not sure it helps explain the rhetorical features in play here very well. Commented May 7, 2016 at 21:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .