On the other end, it's fun when you encounter a bug and go search for an answer and end up reading an answer on Stack Overflow that _you wrote_ 5 years ago and totally forgot about it.
Haha, this happened to me for the first time recently. Asked a question, didn’t get any answers, ended up updating my post with the answer I eventually found. Even had a couple of responses thanking me for the follow up. Five years later, ran into the same problem and forgot the answer, my answer was the top result on google.
I was once looking to see if there were any projects or discussions regarding <insert niche domain> via the google search "<niche domain> Hacker News". I clicked on the top link because, read the comment, and was annoyed that it didn't actually address the <niche> things I wanted it to.
Then I realized I wrote the comment. I didn't address the <niche> things because I was looking for it then and I'm stilling looking for it.
Equally fun is using a package or a part of it that you haven't used for a few years and going to read the docs for a certain feature... and realising you're the one that wrote those docs :)
I heard a saying once: "all developers should be embarrassed about code they wrote more than a year ago" as a (cheeky) measure of ongoing growth and development. :-)
Interestingly, I recently looked back at an old disk drive with my first "real" unfinished side-project which I started as a teen learning to code.
And, to my surprise, it was not _that_ bad.
Sure, it was full of naively implemented stuff that could have been implemented way better. But, even a decade and a half after, it was pretty clear to read, and it was decently organized.
And, in some ways, I preferred this code to the one I'm writing professionally. I was honestly prouder of myself as a teen than myself as a professional programmer.
The difference, I think, is that I had a clear idea of what I wanted to achieve for this project to be considered as definitely finished. Since I started working on code (for money) I've always been working on never ending projects. This industry (and me, as a professional) is obsessed in writing code for long term maintenance and evolution instead of effectively finishing products.
So, to get back on topic, I'm not sure you really write better code with time. I mean, yes, you totally do, but it's not as important as learning how to code for others to be able to understand and modify it with constraints you can't even imagine.
And I saw a lot of people writing super nice open source side project and then, when you work with them on some professional level, well, they still write the same shitty code as everyone else.
I think you progress mainly by learning the type of code not to write. There is a large permutation of valid program terms that can achieve your desired result, and it takes time to know what sorts of permutations are unnatural or express "awkward" programs with undesirable properties.
Like when you learn a natural language's vocabulary, but you still need to figure what conjunctions of words are not intelligible or natural phrases to fluent speakers. Phrases that have ambiguous meanings or otherwise generate confusion.
I think there's a comparable notion of fluency in programming that goes what most people mean they say they're fluent in a programming language.
The code you wrote a year ago should have good points and bad. If it is just bad, then you either started programming a year ago, or should perhaps start thinking about changing jobs.
If you are actually improving then there should be some good in there (you got better from two years ago right?). If you can't identify that good, then either you are just chasing fashion (that perfectly good construct from two years ago is now out of fashion so it is "bad"), or you haven't improved your ability to tell good code from bad and just calling it bad because you are unfamiliar with it.
If you want to actually get better at code then you should do a real review of the code you wrote a year ago. Where did bugs occur in the code you wrote? Is there something that you could have done to make it less error prone? Is there code you wrote that is easy to understand? What design choices can you make so that more code ends up in the good code camp? How were the bugs detected? Can I integrate that in to what I do for testing? Then actively practice moving your code in the good direction and away from the bad.
Anything less is chasing fashion and using familiarity as a good and unfamiliarity as bad. "As is" it is a pithy blog post for Coding Horror, but won't get you there. Pursuing greatness requires directed improvement
Pretty funny, about 15 years ago I started looking back at myself a year ago and decided that until that dude from a year ago looks like an idiot then all is well with my life. Hasn't failed yet.
I honestly find that kindof frustrating. I look at code I wrote a year ago and think - why didn't I do it this (better) way. And I also think - haven't I learned to write decent code by now? Why do I keep writing code like that when I should know how to write it better.
I don't mean this sarcastically, you're probably an better coder than this comment implies, but what you described is the mind's mental content that should motivate you to write "decent" code.
Do you only feel this motivation when you look back at old projects? Perhaps the improvement could be in organization (code-level or otherwise) such that you do not feel lost or confused looking at your old stuff.
I've read that and think the saying is fundamentally wrong. If you're constantly embarrassed at code that is only a year old, I think it's much more likely that you are chasing fads rather than actually improving your code quality.
I would go as far as to say that it's a negative signal, because instead of improving code quality you are just changing things that don't really matter.
I've seriously considered removing some of the older semi-popular projects from my github solely because I would be embarrassed to show them to a prospective employer, or even other developers.
In the end I think it's actually kind of fun to look back through the code though, and think "surely I should have known about X back then... Why didn't I just do that instead."
As someone who looks at GitHub accounts as a resume, I can tell you that improvement over time is amazing to see. Assuming it’s clear what’s most interesting or recent.
After about 20 years of doing this (not particularly as a solopreneur), I understood the following: I sucked really bad yesterday compared to today and today I'm sucking so much more than I will tomorrow. And it makes me really happy that I can still say this. The moment I won't be able to say this anymore, is the moment I'm done and I can finally die.
Well, the fun thing is that at the moment you expire you can be sure that you sucked the least in your life but some young and inexperienced coder will still look at your code and ask “Who wrote that shit?” :-)
While I am not solo, I have still been around for longer than anyone and the primary maintainer of a few repos. I tend to skip straight to "WTF was I thinking", because if its weird it was definitely me.
I am working on a fairly ambitious project. It is in the stages where we are nearing the end, and the tofu is getting firmer.
I had an issue, last week, where a bug was caused by an omission I left from an SDK that I wrote, maybe, eight years ago. It was a simple thing. I didn't add a "RefCon" to a server interaction, so I couldn't attach a reference context to a callback. This is a classic pattern, that I've used for decades, and I have no idea why the hell I didn't add it to this SDK. I suspect that it might be that the SDK was for a fairly wide audience, and I probably thought that they wouldn't understand it. So here I am, paying the price for underestimating my user base (which, so far, is Yours Truly).
Anyway, the "fix" was to implement a semaphore, and treat the call as blocking, which is awful. I really need to go back and change the SDK, but that's a fairly fundamental change, that I can't afford, right now (the SDK tofu is rock-hard).
I'm not a solopreneur but instead a corporate drone, and every time I git-blame questionable code, it's mine. But like others have said, if you're not embarrassed of something you wrote a year ago, that's not good.
That's another old saying - you should try to make code readable not only for the sake of other developers who will work on it in the future, but also for your own sake...
I once worked as a freelancer for a tiny company that at some point refused to pay me for one day of work. One of their reasons was that my code wasn't up to their standards. I could see in git that the code they complained about was actually written by their lead (and only) developer. They still didn't pay, though.
I loved those moments, the work was done, you moved on, and they came with all the ammunition they collected to wiggle out of payments.
The trick is to give them easily defuseable bad ammunition when they "sneak" around to collect. If you disassemble all their arguments and have emails were they were informed, you can trash them thoroughly.
Unpayed though. Cause even good arguments cant help broke little shops.
I talked to a lawyer, and it just wasn't worth going after them for this amount. I wrote it off as a valuable lesson and went to make more money elsewhere.
Unless you are a citizen of the same state the corporation is, you’ll need a lawyer when they file a removal petition to have the case moved to federal court on the basis of diversity jurisdiction.
And if you don't consult a lawyer to prepare for small claims court, you stand a decent chance to be blindsided by that or something else.
Do it anyway. For them to hire a lawyer to determine this, then they have to pay quite a bit of money. It is quite possible they might be bluffed and pay up, or decide it is cheaper to pay up, and then actually pay up.
If the initial action costs nothing, you have nothing to lose, but they will almost certainly lose something. If you do nothing it will cost you nothing also, but you have no chance of gaining anything at all.
They don't need to hire a lawyer to determine it, the junior paralegal in the in-house counsel’s office with a checklist will do just fine, since all the information needed to make the determination will be on the papers they are served with.
> If the initial action costs nothing, you have nothing to lose
Not at all true; one of the other standard techniques for getting things out of small claims court is for the defendant to find anything about the interaction in question that they could countersue for that would raise the amount in controversy above the small claims limit (since the requirement for linked counterclaims to be handled in the same case and the small claims limit interact to requiring moving the case when this happens), even if it is something that they wouldn't sue over otherwise.
Haha, yeah. My reaction to the title was "my past self, usually." I've seen utterly horrible code written by people who I consider myself leagues beneath. Sometimes git blame is a lesson in humility.
