Hey guys, I need some junior advice. I work at a small startup in a team with 2 other backend developers.

The "new" guy studied at a university for a few years. He writes beautiful code. I try to learn from it and use his short hands a lot. I came from highschool and don't have a degree in it (yet).

I recently wrote a piece of code which handles some timeslot logic. I was really proud of it.

New guy needs to fix a bug and add a few things. He completely refactors my code and makes it more structured and partly better. The logic stayed the same.

It sort of bothers me that he touches my (precious) code. How do you guys handle these things?

@irene he did but fixed them

He made ur code better, thats a good thing. Learn from it and improve urself

@irene It's not really a problem just that it's painfull that I spend my time and motivation in some piece of code and the next person completely rewrites it.

@irene Feels like all my time and hard work just got wasted you know?

@SevenDeadlyBugs Ah oke thanks. It's just something I need to learn I guess

@irene Fair enough

@Jifuna I understand the feeling.

But make the best of it and learn from how he did.

I have experienced similar multiple times as I don’t have university schooling and all colleagues have.

But I found out that while the have a better formal education I more than make up for it with ease of learning so within a year or so I have usually caught up or surpassed them, at least in some areas.

And after a while you learn not to be bothered.

As its said, if you are the smartest in the room, its time to find another room ;)

I usually invite junior devs when refactoring their code so we can go through the changes. I would recommend you ask him for this, that way it's not just him rewriting it.
Collaboration is key here, changes can be made for so many different reasons, accommodate new features, fix a bug, performance etc. I want to know why someone changed my code so that I can improve and learn.

At my current assignment we're slashing each others code almost daily but we always discuss the reasoning behind it.

@Voxera Thanks, that helped me.

@netnut Good point, I'll ask him about it because he isn't the most communicative person :P

@Jifuna people not beeing communicative can be difficult of course but I hope you can get around it. Not having regular pair programming or code reviews usually results in crappy code.

My advice is: Don't be proud of your result. Instead, be proud of the way you got there.

You learned how to write good code and applied that. With rational thought you solved timeslot handling. Nobody can take these from you. And as you said, your coworker even improved your code. You learned one more thing to apply next time.
And let's face it, your code probably won't be around in ten years anyway... and if it is, everyone's gonna hate the "legacy code". 😉 But hopefully, YOU will be around and still applying what you learned.

IMHO, pride of the result is essentially "the dark side". I know it's tempting, and taken to the extreme ("Don't touch MY code!") makes you difficult to work with, with an ego problem.

You haven't wasted your time. You gained experience. There's nothing good in keeping back an improvement just for the sake of the invested time in the original code.

Most of the code that I write and that reaches some state we'd call production ready got refactored multiple times. I'd even say there was more time refactoring than writing the initial version. And that isn't a bad thing. When you code you mostly try to find a solution to a problem. But you don't know the solution yet and often you don't really know the problem either. So once you have your first solution it won't be perfect but you have now much more experience in how the problem looks and how it can or cannot (even more important) be solved. Sometimes throwing away and starting from scratch (with your newly gained experience) yields the best result.

About your colleague, I'd suggest to go through the changes with him and let him explain them to you. It helps for your both understanding.

I think the comments people are saying here like "oh yeah, you should definitely embrace it" should be taken with a grain of salt.

That tends to be true **generally**.

But here, we are trusting you when you say this guy's code is better, and we have no access to this code.

I say this because I've been in many situations where some people refactor things into "smart" code but the code to me is worse. For example, overusing design patterns.

In any case, I'll take a developer that abruptly changes my code over a developer doesn't give two shits about refactoring.

And agree with @netnut, he should let you know when he's refactoring other people's code.

In code discussions, or small pair programming sessions, each party can defend their code and the reasons why they think is good. People can change their mind, learn, and try to reach consensus.

take it as a challenge. Learn from his code, if you don't understand what he did or why he did something ask him if he can explain (learning best practices, or sometimes just opinions). And next time apply them to your code and see if he rewrites less.

@Jifuna also, I tend to be the biggest critic of my own old code and if I ever look back on a piece after some time and cannot find ways to improve it it means I have failed to learn something new ;)

You should be proud that you solved it to begin with.

Another thing, its almost always easier to find ways to improve something than to write it from scratch unless its very easy or you have a very detailed blueprint.

Its mot certain he would have made as good a work if he did not have your previous work to build on.

Thats one if the reasons pair programming exists. Being two on the same code might not go twice as fast but you often end up with netter solutions and better code as you have the opportunity to use the experience of both.

And even as a senior I still learn new things from new colleagues, thing I might have missed or new ways I was not familiar with.

Especially with SQL ;). Where I often find a “new” command or way just to later realize it has been there fir many years ;)

I think it’s best to shift the way you view it.
You shouldn’t think of it as “my” code.
Try and detach yourself from it.

Also, maybe your colleague only realised there was a better way to do something once they saw your solution? A lot of the time your first solution won’t be perfect and it’s just natural to update it if a new requirement comes in, or if your touching that area of the codebase again.
It’s likely that your work led them to a better solution!

If it’s not clear why they refactored it then just ask. Come from a place of learning and self improvement. Just don’t take everything they say as gospel.
Sometimes they will have a lot of their own opinions in there, but it’s a good chance to see how other members of your team think.

@irene looks a bit like a function for splitting a string I wrote, lost of * ++ and [] and a few letters here snd there ;)

Works well but hopeless to read :P

Take it as an honor. Someone was so interested in your code that they spent all the time and effort to study and even improve it. There exists such spaghetti that no one wants to touch.

You have to let go of your ego. There is no such thing as "my code". There is code and code constantly evolves.
If you work in a team, eventually someone will change some code you wrote and yes sometimes they will completely refactor it and there is a chance that your future self will be that someone.
I don't see a problem with this as long as the team agrees that the refactoring made the code better. Otherwise you should raise your concerns and that is where code review comes into play.

@irene pointers are powerful, but hard to debug.

I remember porting a list component from pascal to c (not c++) and had it hang the computer totally. This was under msdos, so no protection from the os.

Could not figure it out for 2 weeks until I finally realized it falsely set a pointer to 0 right before calling free on it ;)

It set it in a function.

And calling free on address 0 was not a very good idea :P

Actually, it's a good thing somebody refactored your working code. It means he cares about the project and he want to show you the way.
So learn the reason why he refactored, don't be afraid to ask.

Your next career steps will be to refactor some junior code...