I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I haven't been working under very experienced people either so they've responded to me with the simple "uhhhh..." and given me no answers. In the end, I end up faulting into habiting into this article's main points.
I'm happy you are not afraid to call yourself "junior". Humility goes a long way to becoming a great programmer.
Asking permission is obeisance but it is also communication. Whoever you asked may have knowledge of dependencies upstream or downstream. By asking, you gave that person the chance to add a little context to the change you propose to make and, quite possibly, prevent the team from working overnight to correct an issue you created. Even with 25 years in the field, I still ask other engineers about changes I want to make. Quite often we talk through any ripple effects before I set hands to keyboard.
Be especially careful in modifying interfaces, library calls, etc. Basically, any module that other systems depend on should be modified with a lot of caution and testing. Your caution should grow at least linearly with the dependency graph.
Over time you will develop a sense of which changes you can make without asking, which changes you should talk with others about, and which ones to stay clear of.
Your primary responsibility is creating good software. Your second responsibility is staying employed. Don't fret over every oddity you see in a code base. Refactoring is good for all the reasons people listed in the comments. Figure out which ones have the highest value and talk with the other developers about them. ("Live to fight another day")
If I am working on a task and code got a bit too messy for my liking, I'd simply refactor, it's simply part of the task. Working != complete. If something goes wrong, it will be easy to revert given it is committed in a sane way (i.e. not loads of unrelated work under one commit).
It's a bit different if you want to do major refactoring (taking multiple days). But with small ones, just do as you go ;)
As a junior programmer in the contracting world, I ask the same as it is also a business question. You do not want to create so much extra work in the process of refactoring that you wind up losing money or running out of time before creating what the client asked for. Asking the super (who is also tech savvy) allows him to worry about balancing the business with the needs of his code base.
I would submit that being a junior programmer in the contracting world is a nontrivial part of the problem. Contracting relies on a lot of really bad incentives that I personally suspect are largely antithetical to good practice.
Yeah, I think the only time you need to ask permission is if the refactor would cause additional regression testing. Depending on the system, and unit test coverage, this may not even be a big deal, but sometimes, if you have a dedicated QC department, they may want to regress parts of the system even if they are covered by unit tests. Such regression could mean dates slip, etc, etc, and perhaps that's why someone might say "no."
I find that it's always worth the time. Even more so when I'm working on a quick fix code someone else wrote. I kind of have a few reasons for it:
1. Making the code cleaner is reducing technical debt. This will help in the long run, and I just sort of do it as I go. It's like tidying the house - it is more efficient to do little things regularly than to have a giant mess to deal with later. The little things make it easier to do something later, because you don't find yourself yak shaving as often to get to the main task.
2. In my personal and observed experience - doing the fixes at first seams like heavy task. "it works, this is just grunt work", but as you get practice at it, you'll find that it helps find bugs, it becomes a habit, and you just do it as you go.
3. It helps me understand the code better. Even if I wrote it. Just because I got it to pass tests doesn't mean I know why at first - but cleaning up the code makes me realize edge cases and what's happening.
One thing that helps is to keep in mind the axiom "all code sucks. Some code is useful" (to paraphrase a famous saying). I know when I code stuff, I tend to do a throwaway implementation or two first, just to wrap my head around the problem, then keep one. After a few months, I'll revisit and understand even better what to do, and rework it again. Then maybe it's decent.
I'm sure there are people out there who can do it great the first try, but they aren't that common. The secret is to not wrap your ego/identity as a programmer/understanding of accomplishment up in the code you've written, but in your ability to solve or lessen the problems that come up.
One big improvement I've made in my code over the years is that I take the time to improve my code. Continuously improving code quality does lead to high code quality, and high code quality reduces maintenance hours (both amount needed and time spent).
Well, it really depends on business objectives here.
If you're writing the code which will live at least a month — definitely. But if you're writing a quick hack of a project or test that you're know won't be around next week, it's often a real waste of time and effort.
And I'm not writing about that theoretically now: for me personally, it's a real problem. Whenever I sit to write a simple dirty hackey thing, I always find myself a few hours later googling for the best way to implement unit tests for this particular case or something like that. Which is sometimes educational, but is very distracting.
The problem is that one-time hacks have a nasty habit of living on and becoming long-lived systems. And it can be hard to explain to users / business owners that just because it appears to work doesn't mean it's "already done".
Writing quick hack code is a good thing if you are in an organization that is disciplined enough to throw it away after you've learned from it.
One practice I personally follow with my team is to always pay attention to when the code you're reviewing is not obvious. e.g. If I have to spend more than a few seconds trying to figure out what a function does, then you're pretty much going to have to either rename it, rewrite it, or (not ideally) do a better job at clarifying through comments.
I think part of the point of this article is to say that your transition into "seasoned developer" status should include developing your own opinions and solutions to the code smells discussed.
