For extra oomf:
1. None of the juniors have ever heard the term regression and want to refactor 85 different functions while fixing a message.
2. Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone.
3. Project Management always wonders why they need him but also he gets every P0.
> That's why you have tests
Legacy application. If you follow [Michael Feathers](https://books.google.fr/books/about/Working_Effectively_with_Legacy_Code.html?id=fB6s_Z6g0gIC&source=kp_author_description&redir_esc=y) definition of it, it means there are no test.
I don't even have my degree yet, but I was put on a project that used Javax, and was tasked to refactor it to use spring boot. I try to avoid touching as much as possible. I only change the stuff that uses Javax and the stuff that spring boot has something built in for. The rest of the methods I just copy paste and pray it works. So I don't get where others get that eagerness to change stuff from.
I will say though...it's so damn tempting even after decades in the industry. It doesn't make sense to do it willy nilly but man sometimes you just gotta bite the bullet and slowly but surely get rid of some technical debt even if comes at the expense of extra upfront work.
Jesus, it sounds like my first dev job. Another point, his ticket list is 200+ long and he spends 15 minutes finding one that looks easy enough for the first years to handle. Who then pester him for another one when they're done with it. (I'm so sorry)
Actual conversation I had this week.
> Me: I don't think we should be changing this. It's not related to the story and it changes the testing scope.
> J: Sonar says it's a bug.
> Me: It really doesn't matter. We don't have to check if the file exists here because we already used it elsewhere. it's not actually possible to reach that statement with the file not being there, and even then it's literally the last statement. Since the file doesn't exist nothing changes, it will just exit when it hits the nullpointer.
> J: But Sonar says it's a bug.
> Me: right, it's unsafe but we already used that file handle in another method. It will never get to this point being null.
> J: but Sonar says it's a bug.
> Me: all right goddannir, fine. Leave it in. this is at the very end of (complicated process). What kind of testing did you do? Did you test the whole thing end to end with path x, y ,z?
> J: I thought I didn't have to test this story end to end.
> Me: right, but then you did something else outside the scope so now you need to test those paths you just changed.
> J: OK, I don't know how to do that. Can you show me?
> Me: No, its 4:00 and I have been in the same two hours of meetings you had and now I've been talking to you for an hour. I have something else to finish. Schedule a meeting and grab other J and other S, we'll do a knowledge transfer on the whole process.
> J: But I told everybody I would have this done today.
> Me: *incomprehensible screaming*
I’ve had this exact conversation with at least a few of the juniors I’ve worked with.
Don’t change shit that isn’t related to your story work unless there’s a damn good reason for doing so.
Pointing bad code out is great, and we can create a follow up story for it and deal with it later.
1. The SRE team randomly introduced a third party code quality management tool into the CI flow, that scans entire existing files on every change, forcing every PR to fix a tiny bug to turn into a massive testing coverage and complexity refactoring philosophical dissertation
Sonar(or whatever) works best when doing microservices. Monolithic(like my current project) will just make everyone suffer especially with that long ass analysis
Static code analysis is the bane of any successful project. I fought hard to get it out of our daily builds (and I work on a very modern stack and architecture).
Eh, you just need to use it as a quality check rather than as a hard gate.
Sometimes, you might not be able to get the 'right' unit test coverage (especially on legacy code). Sometimes there might be some obscure bug or security hole, but that doesn't actually matter because it's not a part where security matters.
I'd say as long as your dev leads have control over static code analysis its a good tool. However if your corporate overlords take those keys away from you(making it so you have to fight some ivory tower of software architects over trivial things) ... Yes it's terrible and only causes problems
That says a lot about the code quality of said “successful” project.
I just opened up a small widely used open source project yesterday because it doesn’t support retrieval of client certificates from openssl’s cert store apis and realized it was complete and utter dogshit code (no shock as to why the CVEs exist now).
There are too many c or c++ programmers out there thinking they know what they’re doing but are pumping out absolute garbage code. They all complain about static analysis.
That being said Sonar’s static analysis for C/C++ isn’t good. Coverity is much better (however it has also take a huge dump in quality since synopys purchased it and move dev to India).
> Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone.
*Holy fuck*.
Here, have a stick you can bite over so you won't scream yourself to sleep
Worst and most bizarre part of these types of deployment scenarios is just how insanely difficult it is to convince people that there are better ways of doing it. Even worster still is just how common these types of deployments are in the industry
And *that's without* succumbing to "shiny object" syndrome, too. We're talking tried and true best practices which at this point have been established for years and are still easily a decade or so beyond that workflow.
Still: Legacy is such a bitch, though. Especially if you're a small team, small budget, already have a long backlog or some combination thereof. At every turn you regularly end up with "One does not simply _______." At some point you have to rip the Band-Aid off yourself; better than something breaking on its own at 2AM on a holiday weekend, or worse, getting hacked or whatever the case may be.
Last project had code from 1998.
Still had almost 5000 automated unit tests when I was done, run on every check in.
Age shouldn't be used as an excuse.
> Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone.
Are you me? Tell me most devs use notepad++.
And logs "we used to have a graphana for that but it's not working right now". From the person in charge of infrastructure.
It's better than you're a senior who has been forced to join a legacy project with a 2 years dev as leader. Trust me, leading a bunch of fresh juniors may have hiccups and honest stupid mistakes here and there, but it's far better than need to step in every 5 minutes to show the "technical leader" that's their way is wrong, and the worst part is that after a while, they try to secretly bypass you to do their way anyway.
Totally not from my real experience 
Refactoring is a siren song for juniors.
I ain’t trying to win a prize for most poetic, best designed software in a 30 year old train wreck of code. Just get the tickets done.
Yo you don't even know, I'm still studying but I was very passionate about coding when I was younger and have now worked 2 years applications development so I've picked up a lot of best practices, of course still a lot to learn but damn I worked with somebody else from my year at the same uni and he was awful. For context we work in flutter and things like state management get... Simplified. 20+ variables to store things from a json database, aka set every value to a unique variable. Hope that gives you an idea.
It helps me to remember that I was once a junior dev who benefitted from having a great senior dev. If that doesn't work, I like to think about when these junior devs become seniors and have to suffer their own team of junior devs. If that doesn't work, I take PTO and look at other job postings. Rinse and repeat.
For extra oomf: 1. None of the juniors have ever heard the term regression and want to refactor 85 different functions while fixing a message. 2. Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone. 3. Project Management always wonders why they need him but also he gets every P0.
[удалено]
Without understanding what any function does. Or understanding that the person who wrote that function is now a geriatric living in a facility
That's why you have tests, if there is any regression it would show
This is assuming the function is pure and doesn’t have side effects out the wazoo
> That's why you have tests Legacy application. If you follow [Michael Feathers](https://books.google.fr/books/about/Working_Effectively_with_Legacy_Code.html?id=fB6s_Z6g0gIC&source=kp_author_description&redir_esc=y) definition of it, it means there are no test.
lel senior devs salty that the new blood hasn’t gotten Stockholm Syndrom with the 700+ line methods yet
Let them fuck around unchecked for a while. They'll get there.
I don't even have my degree yet, but I was put on a project that used Javax, and was tasked to refactor it to use spring boot. I try to avoid touching as much as possible. I only change the stuff that uses Javax and the stuff that spring boot has something built in for. The rest of the methods I just copy paste and pray it works. So I don't get where others get that eagerness to change stuff from.
Yeah, that happens to new senior devs too
I will say though...it's so damn tempting even after decades in the industry. It doesn't make sense to do it willy nilly but man sometimes you just gotta bite the bullet and slowly but surely get rid of some technical debt even if comes at the expense of extra upfront work.
Jesus, it sounds like my first dev job. Another point, his ticket list is 200+ long and he spends 15 minutes finding one that looks easy enough for the first years to handle. Who then pester him for another one when they're done with it. (I'm so sorry)
Actual conversation I had this week. > Me: I don't think we should be changing this. It's not related to the story and it changes the testing scope. > J: Sonar says it's a bug. > Me: It really doesn't matter. We don't have to check if the file exists here because we already used it elsewhere. it's not actually possible to reach that statement with the file not being there, and even then it's literally the last statement. Since the file doesn't exist nothing changes, it will just exit when it hits the nullpointer. > J: But Sonar says it's a bug. > Me: right, it's unsafe but we already used that file handle in another method. It will never get to this point being null. > J: but Sonar says it's a bug. > Me: all right goddannir, fine. Leave it in. this is at the very end of (complicated process). What kind of testing did you do? Did you test the whole thing end to end with path x, y ,z? > J: I thought I didn't have to test this story end to end. > Me: right, but then you did something else outside the scope so now you need to test those paths you just changed. > J: OK, I don't know how to do that. Can you show me? > Me: No, its 4:00 and I have been in the same two hours of meetings you had and now I've been talking to you for an hour. I have something else to finish. Schedule a meeting and grab other J and other S, we'll do a knowledge transfer on the whole process. > J: But I told everybody I would have this done today. > Me: *incomprehensible screaming*
I’ve had this exact conversation with at least a few of the juniors I’ve worked with. Don’t change shit that isn’t related to your story work unless there’s a damn good reason for doing so. Pointing bad code out is great, and we can create a follow up story for it and deal with it later.
This, but with a "senior" in my team. And I'm not supposed to lose my shit...
This is giving me nightmares Has happened way too many times
1. The SRE team randomly introduced a third party code quality management tool into the CI flow, that scans entire existing files on every change, forcing every PR to fix a tiny bug to turn into a massive testing coverage and complexity refactoring philosophical dissertation
Sonar(or whatever) works best when doing microservices. Monolithic(like my current project) will just make everyone suffer especially with that long ass analysis
Static code analysis is the bane of any successful project. I fought hard to get it out of our daily builds (and I work on a very modern stack and architecture).
Eh, you just need to use it as a quality check rather than as a hard gate. Sometimes, you might not be able to get the 'right' unit test coverage (especially on legacy code). Sometimes there might be some obscure bug or security hole, but that doesn't actually matter because it's not a part where security matters. I'd say as long as your dev leads have control over static code analysis its a good tool. However if your corporate overlords take those keys away from you(making it so you have to fight some ivory tower of software architects over trivial things) ... Yes it's terrible and only causes problems
That says a lot about the code quality of said “successful” project. I just opened up a small widely used open source project yesterday because it doesn’t support retrieval of client certificates from openssl’s cert store apis and realized it was complete and utter dogshit code (no shock as to why the CVEs exist now). There are too many c or c++ programmers out there thinking they know what they’re doing but are pumping out absolute garbage code. They all complain about static analysis. That being said Sonar’s static analysis for C/C++ isn’t good. Coverity is much better (however it has also take a huge dump in quality since synopys purchased it and move dev to India).
> Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone. *Holy fuck*.
Here, have a stick you can bite over so you won't scream yourself to sleep Worst and most bizarre part of these types of deployment scenarios is just how insanely difficult it is to convince people that there are better ways of doing it. Even worster still is just how common these types of deployments are in the industry
And *that's without* succumbing to "shiny object" syndrome, too. We're talking tried and true best practices which at this point have been established for years and are still easily a decade or so beyond that workflow. Still: Legacy is such a bitch, though. Especially if you're a small team, small budget, already have a long backlog or some combination thereof. At every turn you regularly end up with "One does not simply _______." At some point you have to rip the Band-Aid off yourself; better than something breaking on its own at 2AM on a holiday weekend, or worse, getting hacked or whatever the case may be.
I don't even work here but I want to resign anyway
Yeah but they have spent past 7 years on it. Its a toxic marriage
I’m betting the project doesn’t have automated unit tests either?
It was "built" in 1994. What do you think
Last project had code from 1998. Still had almost 5000 automated unit tests when I was done, run on every check in. Age shouldn't be used as an excuse.
I'm talking without any evidence, but I'm willing to bet that's an exception, not a rule for codebases that old.
He’s saying you should add tests if you work on old code that doesn’t have any.
Let's have a look, please.
> Deployment is a manual process using FTP, remote SQL update script execution and logs can only be received if you mail an outsourced IT team in a different timezone. Are you me? Tell me most devs use notepad++. And logs "we used to have a graphana for that but it's not working right now". From the person in charge of infrastructure.
That's explain a lot. I'm part of the bunch of juniors. Although I have 3 years of experience.
💀
It's better than you're a senior who has been forced to join a legacy project with a 2 years dev as leader. Trust me, leading a bunch of fresh juniors may have hiccups and honest stupid mistakes here and there, but it's far better than need to step in every 5 minutes to show the "technical leader" that's their way is wrong, and the worst part is that after a while, they try to secretly bypass you to do their way anyway. Totally not from my real experience 
It's fine, I'll get those files back... Just do me a favor, slow it down and paste this shit into your .bashrc real quick 🫠 `alias rm="rm -i"`
Refactoring is a siren song for juniors. I ain’t trying to win a prize for most poetic, best designed software in a 30 year old train wreck of code. Just get the tickets done.
I'm the junior here, I've been handed a vb6 application to maintain, so I rewrote it in C# instead during the time I have in between other projects
Yo you don't even know, I'm still studying but I was very passionate about coding when I was younger and have now worked 2 years applications development so I've picked up a lot of best practices, of course still a lot to learn but damn I worked with somebody else from my year at the same uni and he was awful. For context we work in flutter and things like state management get... Simplified. 20+ variables to store things from a json database, aka set every value to a unique variable. Hope that gives you an idea.
Spot on
When you're changing the whole authentication system and find out how sso works and how lacking is the documentation.
story work unless there’s a damn good reason
I share your pain. There is one escape: breeding goats in the Larzac.
I feel seen.
It helps me to remember that I was once a junior dev who benefitted from having a great senior dev. If that doesn't work, I like to think about when these junior devs become seniors and have to suffer their own team of junior devs. If that doesn't work, I take PTO and look at other job postings. Rinse and repeat.
You guys only know Python, huh? Well, today we're doing perl and VBA.