DEV Community

edA‑qa mort‑ora‑y
edA‑qa mort‑ora‑y

Posted on

Do you recognize your code 6 months later?

"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

There are many angles to this quote, and we look at several of them in the show. I take the view that you should be able to recognize your code, and you should be able to be productive in it again, especially after only six months. Though, as time goes on, you'd expect code to look different, as you learn new things.

Stephane says he has problems recognizing code he wrote a few weeks ago.

play pause Edaqa & Stephane Podcast

Do you recognize your own code? Or are you horrified when you go back?

Check out the show notes and read my book.

Top comments (31)

Collapse
 
databasesponge profile image
MetaDave 🇪🇺

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.

Collapse
 
elmuerte profile image
Michiel Hendriks

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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

Collapse
 
databasesponge profile image
MetaDave 🇪🇺

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.

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

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. 👹

Collapse
 
awwsmm profile image
Andrew (he/him)

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
tvanantwerp profile image
Tom VanAntwerp

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!

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
tvanantwerp profile image
Tom VanAntwerp

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.

Collapse
 
simoroshka profile image
Anna Simoroshka

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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

Collapse
 
simoroshka profile image
Anna Simoroshka

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.

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
nestedsoftware profile image
Nested Software • Edited

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).

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
nestedsoftware profile image
Nested Software

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...

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
fluffy profile image
fluffy

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
fluffy profile image
fluffy

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.

Collapse
 
rrampage profile image
Raunak Ramakrishnan

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
xowap profile image
Rémy 🤖

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

Collapse
 
gzuzkstro profile image
Yisus Castro✨

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 😎

Collapse
 
elmuerte profile image
Michiel Hendriks • Edited

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.

Collapse
 
xowap profile image
Rémy 🤖

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