Hey all, I want to know how you all deal with management and pushing tech debt work. Here's a little bit of background on my current situation, and I'd love to hear how you'd deal with it.
I've been in the profession for about 8 years and had a high-level job at my last company where I oversaw a huge amount of modernization work (bringing an old Laravel codebase up to PHP 8, putting all sites in Docker images for the new cloud infrastructure etc...).
I recently got a new remote job with a pretty high salary (I swear this is relevant and not a brag) with a company that has an ancient tech stack. During the interview, we talked about modernizing the company's stack and seemed to be quite important to them. I really like the company and the people working there and I've been really welcomed there. I was brought into the role because of my experience with modernizing code and I worked for a competitor before joining this team.
The tech stack here is pretty simple and ancient. It does work, but it causes a lot of issues. They're using a monolithic Apache server for all of the websites we manage which each dev has to set up with virtual hosts. My first main project is working under a senior dev to scope out a brand new Laravel API which is all modern tech, no outdated PHP versions or anything.
I was pretty pumped the past few weeks but today I hit a lot of roadblocks in working with him and kind of want to hear what you guys feel about the situation.
We're building out an API specification and he insisted that we do it in a Google document, which I suggested we look at an OpenAPI specification instead so we didn't have to keep repeating request bodies and responses. He came back and said something along the lines of: "I don't really want to learn YAML because I don't have time, so we'll stick with the document.". My wrists and fingers still ache from having to copy, paste and edit each request and response manually. Google Docs isn't a great solution for generating API specifications.
Then after that, we bootstrapped the main Laravel application. It's the most recent version of Laravel, and I realised that he'd committed the whole vendor folder to the repo and had gone through the .gitignore files in each dependency and removed stuff that would mess with it. I asked why he did it like that, and he said: "we won't be using Composer because our servers don't have it". Our other applications are running on an older version of PHP so I said we'd need a new server anyways, so why don't we do it the way that Laravel suggests with CI/CD pipelines? He comes back and says "We don't use Composer, and that won't change.". He's been pretty cold to me ever since I started.
Thanks for sticking with me, now back to the salary. How should I approach my manager (the Lead Developer) about this without making it seem like I'm tattling on the Senior? The salary is way more than an average Laravel dev and I know I'll feel bad if I say nothing. I also don't want to dull my skills with newer technologies because I'll struggle in my next role when/if I move on. I spent 3/4 years at my last role and then moved onto another role which only lasted 3 months before coming into this role, so I don't really want to change jobs again for a while.
I'd really value your opinions in this as professionals, even if the technology I've mentioned isn't familiar to you! How would you deal with this situation, especially when it comes to management that don't understand the problems that ignoring tech debt can cause?
I admit that I feel for the senior dev in this story.
I've been in this situation before, you're stuck maintaining a combination of older systems, and you need to add another one with some new team-members. It's going to have the latest technologies like Angular / Beanstalk / Webpack, etc... Then the new guy quits / gets into an argument / doesn't make it through probation, etc. and now you as the senior dev are stuck maintaining a raw PHP 5 / PHP 7 / PHP 8 / Angular / Beanstalk / Docker combination. Let's not talk about Laravel's custom build environment that they've been pushing for a while that basically no one seems to use. I've come to especially dislike CI/CD systems as not only are they flaky and a pain to set up, but I've also seen people get locked out of the management permissions and then I'm stuck doing keyhole surgery to triangulate issues. As someone still on their probation, the senior dev probably has some concerns with letting you give suggestions regarding the tech stack, once it's clear you're going to stick around then your suggestions would have a lot more weight.
Asks yourself, is this an issue worth picking a fight over? Is composer so critical that you're willing to lose your job over it? What about OpenAPI, are you willing to give up your job over not having it? I think it's worth taking a step back and re-assessing, IT will always have word salad new technologies, they come and go, but they don't really change all that much about the project so I wouldn't get too attached to them.
You as a probationary dev, should absolutely not under any circumstances bad mouth your senior to the lead, given that you're new they have no reason to take your word while your senior will have completed projects under their belt. The only thing that it can do is make you look unreliable to the management.
I wouldn't necessarily say OpenAPI and Composer are new technologies, they're tried and tested and commonplace across most PHP projects. I totally get his point. He's an older dev who's sat comfortably for too long with an ageing stack, and now is completely behind the new guys who are coming in from other companies and wanting to change things.
I think the place we disagree is that I believe technology is a place where progression is a hard requirement of the job. Computers get better, customers get more demanding, old solutions improved. You need to improve, every day.
My issue is more when the response to a new piece of minor technology that will make our lives easily is: "I don't want to learn YAML".
If you're determined to turn this issue into a battle of self worth between "good IT people" and "bad IT people" I can foresee that you're going to lose this well paid job in a really obvious and predictable way. Given that they pay well, why would they waste their energy fighting with a developer when they can just get a new developer with similar skills that's willing to work with them?
Which is fair, and I'd give the same response, I don't want to learn YAML either. In fact YAML seems to be a perfect example to use. In the beginning was XML, and XML sucked. For many, many reasons. Then we got JSON, JSON fulfills a similar function to XML but is much better in basically every single way. YAML is not better than JSON, but it is one additional thing that now exists. That describes a lot of new tech, "it's not better than 'x', but it does exist", and once implemented, will have to be maintained forever.
I mean, you probably could persuade your senior about composer and OpenAPI with the right approach, but if you're determined to turn it into a struggle it stops being about the technology. I hope you didn't say "You need to improve, every day." to their face, because at that point you've basically insulted them and they would seriously start questioning if your skills (which you have yet to prove) are worth the hassle of dealing with that every day.
You should consider, is this about the technology, or is it about your image as a "programmer" and wanting to always align with the mental image of being a "good developer".