There have been times where I’ve considered pulling code down from the WordPress plugin repository or from GitHub because the way in which I write my code now differs from how I wrote my code when I was working on those projects.
And surely you know what I’m talking about: It’s not that the plugins don’t work and it’s not that they necessarily cause problems for anyone, but the open source nature of what they don’t necessarily represent what we’re capable of doing now or how we’re capable of doing it now.
Does that make sense?
Are You Look At My Old Code?
I mean, at one point in time we approach problem-solving in one way and we end up writing code that corresponds to what we know and how we think the problem should best be solved.
Fast forward years or even just months later we may have have taken a class, read a book, heard a lecture, or something similar that has completely changed the way in which we approach writing code. I think this is especially true in the world of object-oriented development, but that’s a topic for another post.
So, at some point in our careers, we have all of this code that’s out in the public – at least if you work in open source – and anyone and everyone can take a look at it. And you know what comes after that:
People are going to judge you capabilities and abilities based on the code you wrote.
And if it’s old code, then how does that make us look? Hello insecurity.
So in order to cope with being uncomfortable with this particular side of open source software, there’s a few things that I try to remember whenever someone contacts me who has stumbled across the work I’ve done.
1. The Problem is Solved
Above all else, the code was written and made publicly available because it solved some problem that someone was having even if it was just the author. And if that’s the case, the code is still useful even if it’s not the most well-organized, academically acceptable code.
And as much as I want to write the most efficient, clean, and well-organized code possible, whatever I’m doing now is likely not going to be what I’m going to be doing months from now. That’s something that I need to accept and move forward.
If someone asks me about it, then sure – we can talk. But I’ll hit on this a little bit more later in the post.
2. It’s For Posterity
I don’t know if the traditional resumé is dying or not, but I do think that sites like GitHub and bringing code samples into interviews and to talks with other people are becoming more common.
Having both old code and new code and everything in between can help build a case from where we were and where we are (and hopefully give an idea as to where we’re headed). This can prove to be useful for those who may be hiring us for jobs as it helps them to know if the work we’re doing jives with what they need in their business.
If anything else, it can serve not only as a reminder of where we once were (because, face it, you haven’t always been the high quality programmer you are now :), but it also helps to serve as a point of reference for how to do something – at least to some degree – for a problem we may encounter in the future.
3. You Should Ask For More
This actually placed to burden of responsibility on the third-party who is looking at your code. That is, if they’re passively reading things you’ve contributed and then have questions about why you’ve done something the way you have, why not just ask you about it?
We have plenty of ways to make contact information – email, Twitter, even GitHub issues or comments – so to take advantage of those if you have questions, and hopefully others will, as well.
Is There More?
This is somewhat of a rhetorical question. Yes, there’s more. There’s always more. But that doesn’t mean that I’m not curious about what you have to offer as it relates to your own experience with doing this.
So what are your thoughts on all of this? Eventually, sure, code becomes dated and incompatible but that doesn’t mean that it can’t serve some type of purpose. So I’m curious as to what you add to this post.
Comments – have at ’em!