New grad been at my job for 5 months Long story short I joined a small team who's go no formal education and very poor fundamentals of software engineering. My code base is older than me in a language that's almost on the top of stack overflows most hated list (don't wanna give too many specifics) Point is that most of the time I spend fixing problems on a code base that I could probably completely re write on my own in under a month of solid work and have it run much better. None of our tables are at all normalized(I asked why and they didn't seem to understand what I was trying to do), duplicated data everywhere across multiple tables, they don't use git and opted for the file share route, no automation, no new technologies (it was almost a miracle I got a new laptop), and most of the time I spend writing docs for myself because there's quite literally nothing documented, but the way the system operates (if that's what you'd call it) doesn't make any sense at all anyway. Zero tests (not that I think we could test the code), and just no cohesive plan of how to maintain any of it. Im quite literally my teams newest hire in the last decade. Most of the time that I've been here I've just been fixing problems and asking why we did the things we did in certain areas, and I just don't know how I can really learn or progress when the things I do implament they don't completely follow because of their lack of fundamentals (things like core concepts of data structures and really utilizing object oriented programming and principles) Any advice of what I should do to make the best of my time? I'm trying to jump ship but even getting phone screens or OA's has been difficult, and I want to at least make the best of the time I have while working here. #engineering #software #swe
First off, it is really common on old proven code that you do not touch what is already running in the field and not broke. This is regardless of language. Every software has bug and many can be hard to reproduce or certify. Second, for young people it is probably not the best route for future growth. This is likely OK for electrical or mechanical field to enter software but not for software oriented guys to start career in. Lastly, there are a lot of reason old system are done like that. Data structure and single copy of data may have size or speed issue or sometimes hardware bugs they cannot fix without some weird workaround. So yeah it is kind of like that. Git is a recent development. It is less than 10 years old. Old code base don't always have these revision control for short code base, and not all teams have them. It is just how legacy things are.
So I'm genuinely not trying to be the guy who's trying to hate but the code base is not proven, we have to do daily manual changes in our data base simply because of the way the code runs and crashes for certain things and the only real fix would be to re write a lot of it to prevent that from happening. Heck our logging system doesn't even work correctly and gives us false positives nearly 10x a day... My team was put together by corporate because they happened to create some sort of automation scripts in their previous roles and then corporate put them all on one automation team because they all had something I common.. We have a corporate git and everytime I bring it up I get the run around of "well we haven't been able to sign up for the class on it because they're not doing In person classes currently" While version control on our system might not even be effective at this point just due to how everything is configured I feel like my team doesn't take learning into their own hands and if it's not offered in a class that's readily available for them then it's best to wait until it is. Im not against classes and that type of learning but waiting around for certain things like that almost seems counter productive..
I understand your point. It is hard for old legacy things to change and businesses do not like taking risk for no reward. I think it is best for you to grow elsewhere, legacy team like that isn't good for early career but changing processes and all do lead to risk. There is also risk of older employees cannot handle changes and decide to quit, causing more headache than worth.
It's fun to write new code, but not going to happen (and your new code would have bugs too). Make minor small changes, one at a time: 1. Version control 2. Tests (correctness and performance) 3. Refactoring. These sound doable, but you'll have to get buy-in for Version control from other people. Keep track of what benefits your changes provide.
Refactoring can also be risky. Sometimes timing bugs will be introduced despite logically identical.
I'd like to do those things but I think tests would require heavy refactoring, and heavy refactoring would require everyone to be on the same page which I think I'm struggling to get my team to do. Even if we did it using the old tech I'm totally fine with that, but I also want to make sure 1. My ideas aren't being forced on anyone and it truly is a team effort - because Im sure they do bring a lot to the table to offer in ways I simply do not see yet (I hope) 2. Obviously I don't wanna step on anyone's toes and be a know it all jerk off 3. I wanna make sure that what I do makes sense to everyone and that what everyone else does makes sense as well I'm not in a position to become a team lead and my team lead seems like he's not pushing to create and maintain a robust system rather than manually going into prod db tables and manually changing data that breaks our system on the daily
I believe that your first few years as a SWE are the most important. If you aren't learning, and if there are no best practices, I suggest looking elsewhere.