I feel that I made the transition from jr to mid level developer when I was able to come into some new code and judge it, instantly pointing out what was wrong and how it could be improved, and how it should've been built. I feel that I went from mid to senior when I would enter that same situation and try to understand the why behind the code (even though I probably still thought it was poorly architected) before passing judgement or trying to "fix" it with a refactor.
You transition from senior to manager when you first try to understand the importance of the code to the business and whether anyone will ever touch it before bothering to understand the code.
Your short comment really triggered my management PTSD. I wrote a huge ass post but decided to delete it and just summarize:
* Senior tradesman -> manager is not a natural transition;
* Senior tradesmen take business into account without needing to transition;
* Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious.
I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application.
I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
Senior developers are the ones who understand the code AND the business. One of their jobs is to keep managers from making stupid decisions that would harm the business. In many orgs, managers did NOT come from the ranks of senior developers.
I always get triggered when a new team member comes in and starts to rename variables in Pull requests and plans out huge refactorings. I‘m like ok you are five minutes into this code without any knowledge why it is shaped and named like this. Not that the person is or isn’t correct it is just how fast people are willing to change working software because they feel they can make it better in an instant. The second reason I get triggered is that I think it is quite rude to the programmers that came before. I have to swallow a lot of pride over the years because of course ones code isn’t without fault. But to point that out from a newbie in the team who maybe only want to proof that they can code? Super hard for me ;)
I still cringe at the memory of my first webdev job out of university. I thought it would be a good idea to alphabetize all of the methods of the behemoth User.rb class of an ancient Rails application.
The other developers let me do it and, looking back, they obviously didn’t want to rain on my parade as a junior dev that was eager to help out and “improve” things, god bless them.
On the other hand, it's also bad when a new person comes in who treats all existing code as gospel and is afraid to fix things that are clearly messy. Or doesn't even see the need.
I think I actually prefer your type, at least they care about improving things, and they're going to make it theirs.
I almost always welcome such initiatives because the new team member brings a fresh perspective and is unencumbered by our existing knowledge. And they don't have that many responsibilities yet, thus they can focus on the code itself. But good test coverage and thorough reviews are necessary to do this.
No don‘t get me wrong. I see this as well and have an inner fight when the typical: Let’s clean this up PR pops up. What I mean are changes that have no real value other than a change from Person X in file Y. Yes one can rename tons of methods and variables. But maybe these names stem for a reason. I have one example where the variable names where generic in nature and the change request renamed them according to the concrete implementation. You can argue back and forth about this :)
I actually think jumping straight in and refactoring is one of the best ways to learn a new codebase. If it's set up consensually and as a learning tool, the combo of refactoring + review from older team members is a great way to learn, even if your changes ultimately don't make it to prod.
The broadest version is that you can let a junior do that if the system is well managed: has tests, the reviewer has good knowledge, there are good rollback procedures, good metrics exist; whatever it is that's appropriate is functioning.
As long as you play around in your own branch and never merge your changes, what's the risk? You can try and make changes purely for the purpose of getting to know the code.
yeah, fair I suppose. Personally, I find that changing things and watching the tests fail gives me a lot more insight than just running the code, but that's just me I suppose.
I agree but I also worry about a certain "Stockhold Syndrome" with large codebases. Sometimes it's the fresh pair of eyes that can see exactly how bad some things are. Once you've learned to understand something you tend to have a rosier view of it.
And sometimes the harder it was to understand something, the more invested you become in it and the more you want to defend it.
The trust to refactor needs to be earned. There is a social dimension to refactoring. People that come to a codebase and immediately start refactoring don’t understand this. They believe they can just make objective arguments and others will accept them.
You will become a master developer when you can explain why the thing never should have been made in the first place and then lead an effort to tear it out and throw it away.
You become a guru developer when you realise that judging any code based on any metric without knowing the full context is often misleading. Yes, in general removing code is good, but does that mean removing the full project and committing that is the best change you can do?
Imagine you're developing a storage with S3-compatible API that is meant for public consumption, but you don't actually have something to store. Then yeah, bad idea to write some sort of storage system.
Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
The problem is that this is always, always harder to sell than a new feature/launch/whatever addition. You might be a master developer but you'll not be the highest paid / highest level.
This is why I like to ask people to talk me through a change that I think I don't like, or might be wrong, before passing judgement. One of two things happens in the process of them explaining:
- they know something about the context that I was unaware of or have an insight that I hadn't thought of and so I learn something and change my mind
- they realise they've missed or misunderstood something, or were unaware of something which I can communicate to them, so they learn something and change their mind. Sometimes this can be as mundane as "this isn't idiomatic, we should prefer the community style.
It's almost always a learning experience for one of us, frequently both. I've learnt a lot over the years of reviewing other people's code.
In the cases where neither of these things happen it's because it's a question of personal taste, there's nothing wrong with the code, I just wouldn't have written it that way. In those cases I leave it alone.
Hrrrm, so that comment was badly formatted for some reason, I think I should have put a blank line between the two cases in the second paragraph which should have been a two item list :/
A non prod breaking scenario I have seen - only towards the end of a fairly long refactoring exercise, when tests for certain edge cases start failing, you finally understand the full purpose of the code you are refactoring.
Not to fall into the obvious trope too much, but: Your legacy code has tests for edge cases? I'm happy when it has any tests. More often, it's untested and I write the tests myself before refactoring the implementation.
I thought the whole point of a true refactoring was that it should not lead to any changes in outwardly visible behavior. If you're changing what the code does, that should absolutely be pointed out, regardless of whether it's phrased as "clean up".
Transition to pro TL: keep the solution to yourself, let everyone speak and piggy back on a team member that comes close to yours without forcing. If no solution matches, also present yours with the added benefit of weighing the pros and cons of the ones before it.
