Projects are like people. Everyone shows great interest when they are being planned and brought to life. Some happen by accident and are more or less unplanned. Initially, everyone is enthusiastic about the new baby—or project. In the beginning, a lot happens, and things take unexpected turns. But after some time, things start to settle, and people's interest fades. Only a few loyal friends remain. Eventually, the project becomes a burden, and very few are willing to take care of it. In the end, many just want to let it rest in peace.
You're not a senior engineer until you've worked on a legacy project (2023)
271–280 of 431 posts
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#272Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…
I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrog…
Yes! #3 is key to making one humble
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#273Most engineers will scoff at the idea of patching up a legacy project if they see the slightest deviation from “best practices”. They will slam their fists on the table and claim that management keeps “piling on tech debt”. They will argue for a total rewrite and dismiss any concern of said rewrite taking years because “this is what it means to have high standards and best engineering practices”. They wear this as a…
They will argue for a total rewrite
in my almost 3 decades in this industry THIS has been the number one way to tell a Junior from Senior SWE. nothing else comes close 2nd
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#274I usually say that when people say “legacy project”, it’s really “code I either don’t understand or don’t like”.
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#275Earlier quoted context omitted.
Imposter syndrome is fueled by colleague deification. It's easy to view smart coworkers as superpeople... until you're reminded that they, on occasion, make dumb human mistakes too.
I’ve found one of the best things I can do to help my jr devs feel more confident (and be willing to ask for help) is highlight my screwups and “basic” things I’ve just learned. It make me seem more approachable and less like everything I say is a pronouncement from on high, it makes them more willing to admit to their own mistakes, it clarifies that we’re all learning stuff all the time and it helps spread knowledge…
I 100% agree with you, and have used the same technique. Showing juniors that you are also human and make mistakes allows them to be less anxious about learning and trying new things. It also helps to keep them from trying to hide their mistakes which can quickly lead to larger system issues.
Of course, you have to have a culture where making a mistake doesn't immediately lead to being let go or publicly reprimanded. I have definitely learned quite a few things about people and code by helping juniors work through bugs that may not have been so obvious (including occasionally finding bugs in 3rd party libraries).
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#276I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations. One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing enviro…
> deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. This sounds like a great way to cause a live-site incident.
It has risks, no doubt about it.
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#277I still remember my first job porting a VB6 code to VB.net. The code was written before object-oriented code was a thing. Back then I thought OO would have solved it. Looking back all it was really missing was a strong type system.
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#278You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.
I used to work for a company where the American devs indented with 4 spaces, and the German devs indented with 2 spaces. When they finally decided to standardize the code style across the company, they couldn't agree on indentation. So, they compromised and everyone started indenting with 3 spaces. I swear I'm not making this up. I worked on one codebase that lived through that transition, and some source files would have all 3 indentation styles scattered throughout.
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#279Earlier quoted context omitted.
I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrog…
> very arrogant My experience, is that this is usually a defensive shell around personal insecurity. On the outside, it looks the same, but internally, insecure people can be reached (not easy), whereas truly arrogant folks (a lot more rare than you might think) cannot. My experience is that most difficult people are actually decent folks, that we can enjoy working with, but we need to adjust to them, and they need t…
> but internally, insecure people can be reached (not easy)
How? Any advice?
Re: You're not a senior engineer until you've worked on a legacy project (2023)
#280Earlier quoted context omitted.
I’ve found one of the best things I can do to help my jr devs feel more confident (and be willing to ask for help) is highlight my screwups and “basic” things I’ve just learned. It make me seem more approachable and less like everything I say is a pronouncement from on high, it makes them more willing to admit to their own mistakes, it clarifies that we’re all learning stuff all the time and it helps spread knowledge…
I 100% agree with you, and have used the same technique. Showing juniors that you are also human and make mistakes allows them to be less anxious about learning and trying new things. It also helps to keep them from trying to hide their mistakes which can quickly lead to larger system issues. Of course, you have to have a culture where making a mistake doesn't immediately lead to being let go or publicly reprimanded.…
Pitching in to your and parent comment but from the junior side to say that yes, this definitely helps :)