You know that feeling of when you look back at code that you wrote a few months ago and kind of cringe that that’s how you wrote it and sense of “What was I thinking?” or maybe even a little embarrassment comes over you?
I’m beginning to wonder if that’s not something that stays with you as you move throughout your career in development. One thing that I’ve been noticing about myself (and I know at least a few others have this feeling to) as it relates to programming is this:
I am in a perpetual state of discomfort.
Maybe that sounds a little grandiose or maybe it sounds even a little ridiculous, but I don’t know how else to explain it. I look at stuff I’ve done and see how I would do it now, and I work on stuff now and know that, given my track record, I’ll probably look at it later and think about all the ways in which I could refactor it.
It’s kind of a vicious cycle, isn’t it?
This Constant Discomfort
The thing is, I’d like to think that the developers who care about what they’re doing are making constant strides to better themselves. This can be done in any number of ways:
- Read books about the subject matter
- Contribute to other people’s projects
- Maintain an open source project in which you interact with others
- Study other people’s code
- Read blogs and other articles all about the subject matter
- …and so on
The funny this is that these types of things tend to seed these thoughts of
Yeah, that sounds awesome – that makes a lot of sense, I’m going to try to do that in my next project.
Or it makes us think:
Man, why didn’t I know about this on that last project I worked on? It could’ve made [whatever-task] so much easier.
And on and on it repeats, right?
So with every project – be it ones that we start from the ground up to those that have existing codebases – we constantly try to use something new that we’ve learned.
The Pre-Existing Codebase
Of course, it’s not always that easy especially as it relates to existing codebases. Whenever you go into an existing set of code and you’re tasked with introducing something, it gets a bit more complicated than with a fresh codebase because you’re having to do a little bit of exploration to make sure that whatever it is that you’re introducing or that you’re patching won’t result in a ripple effect throughout the rest of the code.
In those situations, sometimes it’s best to refrain from trying anything too new or too over the top unless you want to deal with accidentally breaking something else.
With a Clean Slate
But when it comes to starting a new project, it’s a completely different situation. You have a clean slate and normally you have a bit more time to actually spend time planning and designing the architecture of what you’re working on.
There’s a really good feeling that comes with that, but I also have been involved in enough projects from their outset to know that excitement can begin to subside once you get into the thick of making something happen and then it becomes more about just getting it done rather than getting it done well.
I don’t necessarily know why that happens, but it does. It probably has something to do with a combination of the freshness of a new project wearing off and with burnout, but I’ve found that if I take enough breaks while working on something, my excitement level tends to stay up and I can stay true to the initial design.
What Are We To Do?
Maybe I’m thinking out loud or speaking only to myself here, but there tends to be a pattern that I’ve found in the types of projects that I work on:
- Given enough time with brand new projects, I can normally plan out how the initial set of classes, functions, and so on will interact with one another.
- If, during the course of development of a new project, there’s scope creep, then the initial design may take a little bit of a hit (though theoretically it should be able to adapt – that’s a post for another time), I can normally course correct and make it happen.
- If given an existing codebase, I normally either spend time refactoring some of the surrounding code to try to make it a bit more readable and a bit easier to work with, or I swing in the complete other direction and play it safe. That is to say that I near-sandbox the code I’m working on such that it doesn’t touch anything else that exists in the system. This is to prevent any latent side effects from occurring.
Are these the only things that we can do for our projects? Of course not, but this has been what I’ve observed myself doing over the past year and it seems to be working alright. The challenge with that feeling, though, is that I’m constantly wondering “Is this really the best way to go about doing [this task]?”
After all, if we’re constantly trying to get better at what it is that we’re doing, and gaining more knowledge let’s us know how much we don’t really know, then it seems like we’re never really going to get there (wherever “there” is).
On top of that, this isn’t a field in which you finally “arrive.” It’s a lot like many other hobbies and professions – no matter how far you’ve come, you can always get better. Unlike video games, there’s always room to level up.
But to bring all of this rambling to a close, this perpetual state of discomfort is something that I think that I’m learning to live with rather than trying to get rid of it. I don’t know if it’s possible to get rid of it, or if I’d really want to get rid of it.
If I did, it would mean that I’d learn to be content with just being where I am, and surely no one who wants to continue getting better at what they do would be satisfied with that.