Do you recognize your code 6 months later?

edA‑qa mort‑ora‑y on February 05, 2019

"Any code of your own that you haven't looked at for six or more months might as well have been written by someone else." - Eagleson's law The... [Read Full]
markdown guide
 

My SQL was always very distinctive, because it did not look like the shoutings of a mad man.

select
  id,
  title
from
  books

etc, instead of

SELECT ID, TITLE FROM BOOKS

It used to irritate people that I wrote function names as DBMS_Lock.Allocate_Unique, which is not to everyone's taste but in the world of Oracle everyone is still writing their code in unreadable uppercase for some reason.

 

For some reason I often capitalize the primary structural keywords like select, from, where, and, or, ...
It is probably to make clear distinction between the various parts of the query.
I also dislike the all-caps queries. It makes stuff so much harder to read.

 

They still haven't upgraded to text editors that do syntax highlighting.

 

Well tbh there are some really good SQL IDEs that will do all that, and enforce coding styles, but they seem to often be used to just make everything uppercase.

It's like they're monsters or something.

I've seen this before...

  • Why do we code this way?
  • Because our IDEs do it that way.
  • Why do the IDEs do it that way?
  • Because we use to code that way.

The cycle of IDE monsters continues to consume us. 👹

 

Not horrified but it does take some time to get back to the state of mind you were in when you wrote it originally. Currently working through this right now, actually. Going back and writing unit tests to remember all the methods I wrote six months to a year ago.

 

Yes, getting back to the same state of mind can take a while. I think as long as you can get into the state of mind, the code is probably okay.

I often work on diverse parts of projects, so I get this even day to day jumping between the parts.

 

I definitely don't remember what I did or why after 6 months. Even longer, and I might forget I wrote it at all. Once I wrote a small tool, only to discover I'd already written it about a year before and forgot about it!

 

I once searched my hard drive for hours looking for a tool I believed I once wrote. Then I gave up, and just started writing it again. Once I saw the code, I realized what name it might have, then searched, and found the original tool.

 

When I compared my duplicate tool to the original, it was eerie how similar it was. Right down to using 90% the same variable names. Really made me think about my consistency as a person over time.

 

I definitely agree with the quote. It doesn't mean the old code is bad, but as @awwsmm points out, there is a lot of stuff in our working memory when we're actively engaged with a project that goes away over time. That makes it feel "obvious" how to do things in the moment, but then later on all that stuff becomes less clear.

For me this really comes into sharp relief with things like configuration, packaging, and deployment. I think that makes it really important to automate as much of such things as possible. I try to create shell scripts that will automatically do the things needed to get an app up and running, and I also try to document why those decisions were made (like why did I change this nginx config file).

 

I automate a lot. But I've also learned to put help syntax on my scripts. Even if it's just a one-line thing, it lets me remember what I'm supposed to do with the script. It's a bad feeling knowing that you had a process completely automated, but can't remember how to invoke the automation.

 

Yes, I put that kind of stuff into a readme.md file at the top of the project. My objective is to set everything up from scratch on a brand new vm only by following the readme. If I can get that to work, I know I have a reproducible workflow...

I religiously create and follow README's as well. I use Makefiles and Fabric files also -- since they have top-level targets I can look at, and they follow common names.

 

I recognize it and I am usually horrified by it. Every time I try to see this as a sign of my progress as a developer and try to learn my lessons.

 

Do you recognize specific things that you'd do differently now, or is it a generic feeling of "this could be better"?

 

A general feeling of "This could be better" comes much earlier, even during the development (and doesn't really mean I will be able to make it better at the moment). After 6-12 months I will most likely know what the problems were. Maybe I used that code and felt pain or I learned new patterns from somewhere.

This is good example of a positive view on the quote. Being able to recognize how you'd do things better is a great indication of learning.

 

I have some files from different stages of my career. The earlier ones both amuse and horrify me at the same time :) . They were precursors to many "aha!" moments when various programming concepts finally clicked.

 

I've got some very old source files sitting around, like 20+ years old. I don't think I'd want to look at them anymore.

 

You made me want to look at some old code. My oldest open source code is from 2005 and... That's terrible. Truly terrible.

 

I generally recognize my code but often think, "Wow, what was I thinking?"

As I get older I also find myself frequently thinking, "Dang, my code could use [random feature], I'm gonna start designing it" and then just as I start writing code to do it I discover... I already did that months ago. And documented it fully.

 

Ah yes, the classic redundant rewrite. I believe I've done that a few times as well. I think it speaks towards making sure your refactoring is fully complete, which involves removing the original code you were replacing -- ensuring it is never seen again.

 

Not even a rewrite, but attempting to write something the first time before realizing I'd already done it. :) Apparently past-me is very good at predicting present-me's needs.

 

For the first 10~15 years or so I indeed thought my previously-written code was terrible but now that's fine for several reasons:

  • Very consistent rules (formatting, linting, naming, etc)
  • Re-reading every commit to make sure it looks nice overall
  • Making sure to write useful documentation
  • And experience I guess
 

Yesterday I spent the day refactoring files of my first project (like a year ago, but feels like 3) that included SASS in orden to "make it easier to write CSS"... Horrified is not enough to describe how I felt reading my own code, but I take that as a sign of progress as a developer, practice and learning have definitely paid off 🙆🏻‍♂️

So yeah, I agree with the quote, it is natural for developers that strive for constant growth 😎

 

I have a rather good memory, so 6 months is easy. Also my style is, sadly, distinctive from my co-workers. So once others make changes to code I wrote I get slightly confused. "why did I write it like this?". Then I check the RCS log and see somebody else wrote those lines.

 

My newer 6mo code mortifies me less than the older code used to, so maybe I'm finally getting closer to reaching the code-cleanliness I'm striving for.

 

Most the time I do, but only in a while I don't...

 

Sometimes not and I wonder how i could do this and I find myself rewriting some blocks of code.

 

I routinely do recognize it, but sometimes it takes a few minutes of study before I think, "oh damn, this is MY code!"

code of conduct - report abuse