Whenever I go over the stuff I wrote in my first years, it's not always that I can't read it, it's more that I don't understand why I did everything in the worst possible way...

I've written some pretty awful kludgy code in the past. I can read it, but it makes me wince.

I'm not saying I'm not capable of writing shitty code now, by the way.

No, that's why, over the years, I've developed some techniques that help to make code understandable.

1. This seems backwards, but NO comments. If code is so complicated it needs to be explained, it is a good indication that it needs to be broken up into smaller pieces. So break it up into functions and literally name that function what you would have said in the comment.

2. No code longer than 1 page scroll (This is a loose rule). If you can't see everything that needs to be understood on 1 page, again, it's a good indication that it needs to be broken up into logical families, like classes. Furthermore, classes can usually be broken down further into an MVC or other similar paradigm so, you aren't bombarded by unnecessary information (like the view) when you are working in the model.

3. Always use long descriptive variable names. Never abbreviate unless the variable is a temporary variable or an iterator. Ex. tmp, or i

4. Keep it bone DRY. DRY requires breaking code up. Breaking code up means descriptive class and function names. The code is literally readable because it is telling you exactly what it is doing.

When I read mine, I begin to cry.

Well the code is beautiful as always but there just aren't many comments so I have to re-understand everything. I don't know, comments make code ugly by taking up all the space... well for small programs that is. Surely there will be essays in my bigger projects.

I read it and am saddened by how much happier I used to be. It all used to be so much more fun.

Frameworks are all about "magic" plumbing that shuttles your data from one place to the next in a completely obscure way. All in the interest of saving you time. Of course, it ain't free, it's paid for by all the extra cruft put in place to make it all happen.

Agile is responsible for a lot of it. When you have interchangeable developers instead of people that focus on what suits them best, all of a sudden you need tools to that even the weakest database guy can get his database tasks done. Agile never fixed the mistrust between stakeholder and developer, it just tied the developer's hands. Terms like "polish the cannonball" are used to beat down and suppress the desire to do things beautifully and just turn software development into a machine in and of itself.

Reading it is no problem, but some of the design decisions... do not necessarily reflect what I would do if I were to try it again right now. A lot of my older code was more ambitious than what I do today - I was trying things which I didn't know how to do already, so you can easily see where the grand plan wasn't fully formed yet.

I've created some fantastic messes. Wrote an ORM framework back in the day that uses the .NET CodeDom to write all logic then outputs source code files, thousands of them, which are then compiled as libraries.

Extending this is a nightmare but I have a few apps that use it exclusively for all database interaction so it lives on unfortunately.

If I need to modify an if statement in the output, finding the code that expresses this if statement is nearly impossible.

#include <unistd.h>
#include <sys/types.h>
#include "some_library.h"
#include "some_logging.h"
//------------------------------------------------------------------------------
// NAME: some_function
// DESC: I can because I use a batshit crazy formatting style normally only used 
//       in military code and device drivers.
// ARGS: -
// RETN: rc - success / error code
// HIST: authored - dev13
//------------------------------------------------------------------------------
int some_function() {
   int rc  = SOME_SUCCESS;
   int uid = getuid();
   rc = do_something_here(uid);
   //------------------------------------------------------------------------------
   // log any failures of users trying to use this.
   //------------------------------------------------------------------------------
   if (rc != SOME_SUCCESS) {
      some_log(SOME_NOTICE, "User %d attempted to do something", uid);
   }
   return rc;  
}

You don't read code, you read comments, and they tell you how fucked up the code below is going to be.

True coders don't bother reading code anyway, because they read the first line, decide that it's total shit, and rewrite the entire program.

I am embarrassed of some of my older code.

If you count Applesoft BASIC, then, maybe

I can because I'm extremely verbose in my coding. No shortcuts and descriptive variables and function names. Anyone can follow my code easily.

Kinda, my first language was Python which is a very procedural language so easy to read.

Depends on what phase of my own coding existence we're talking about. . . For example, my Java coding life cycle goes kind of like so: Yes up until when I got my first patterns textbook, figured out what interfaces were for and what System.Reflection was, then no until I actually figured out how NOT to use those things all of the time. . . I have quite a few "Too clever by half" implementations that look strikingly like spaghetti code in that era. . .

I recently rewrote an old program of mine which was originally about 10k lines of code and is now about 600. Rewriting it took away some of the shame.

Most of my code is kept very simple. If there is a way that isn't exact, but close enough, and it reduces enough, I'll use it, and add the extra later. I get away with it by calling it prototyping, and my boss will usually just use the prototype and not have me dev further.

I'm at the point where it's readable, but incredibly poorly written. I've still got an algorithm I translated from Python to C about a year ago, saved just for giggles. It's a direct translation that mallocs new objects where Python created new ones, and leaks so much memory it's barely usable.

I've always heavily commented my code. I think it's a chick thing. So I can always understand exactly what I was attempting to do.

If your code today is identical as yesterdays, you aren't progressing. I have a few moments where I just change my coding style all together, it happens once or twice a year. Recent stuff shouldn't be bad but like 5 years ago yikes.

I can read it alright. Understanding it is the tricky part. Depending on the language it ranges from "Alright, now I know what this code does." to ... less pleasant assessments.

I guess everybody who didn't have a stroke? Is everybody proud of their work? That is a different question all together.

Pretty good, I write documentation in my code.

Easily. I comment everything.

If you can't then you aren't a coder.

I learned early to comment profusely. I've learned a lot about program design and algorithmic complexity, but thanks to my comments I don't have any trouble.