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.
ell.stackexchange.com/users/9627/slebetman
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
ell.stackexchange.com/users/33732/Daim
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.
ell.stackexchange.com/users/16318/Catija
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.
ell.stackexchange.com/users/24691/Laurent Duval
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.
ell.stackexchange.com/users/31333/Hay
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.
ell.stackexchange.com/users/33733/JiteshNK
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.)
ell.stackexchange.com/users/626/Lightness Races in Orbit
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.
ell.stackexchange.com/users/33825/Hazell
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?
How to understand "don't code today what you can't debug tomorrow"?
ell.stackexchange.com
<sentence-meaning>
ell.stackexchange.com/questions/89208
ell.stackexchange.com/users/2215/Sayakiss
Basically it's saying that you shouldn't write clever and/or tricky code because debugging such code later will be very hard. Write clean code today because you may not have time to fix it tomorrow.   The quote basically encourages programmers to "not be too clever" when writing code, because the debugging part is harder than the coding itself. Therefore, if the code is too complex, debugging it will be a nightmare and it may even not be understandable after a period of time. It can also be perceived as a play on the phrase "Don't put off until tomorrow what you can do today", encouraging programmers not to procrastinate and to write code in a simple enough way that will not be too time-consuming to debug.
The quote basically encourages programmers to "not be too clever" when writing code, because the debugging part is harder than the coding itself. Therefore, if the code is too complex, debugging it will be a nightmare and it may even not be understandable after a period of time. It can also be perceived as a play on the phrase "Don't put off until tomorrow what you can do today", encouraging programmers not to procrastinate and to write code in a simple enough way that will not be too time-consuming to debug.