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?
Do you wanna be right? Or, do you want to have a long term career at this place?
It's the same argument I make with my motorcycle-riding friends who like to ride aggressively and "own" their spot on the road. They live for the "I'm allowed to be here just like you are" approach. And while they're not wrong (they do have the right!), they're not thinking about the problem the correct way. They can be right AND dead. As they say, the cemetery is full of people who had the right of way. Sorta irrelevant if you are dead, though.
Same idea with your career. There will be so many times where you can see a better path. You can see the "right" way, but the business, for whatever reason (that you frankly may not even be aware of, based on your level and seniority) chooses to do the "wrong" thing (from your perspective). You have a choice at this point, either make a stink, or calmly (and in email), share your concerns with your direct supervisor.
Once you make a stink... no going back. You are forever that person who stood up and tried to derail this project, without the full picture... I guarantee others will talk. "Who does that new person think he is?" or "why would they get in the way without even understanding all the context" etc etc
Frankly, you likely don't have all the info. And you are at a point in this job where you can make friends or enemies... if I were you, I would not die on this hill. You don't own this project. It's not your skin in the game. Just do what you were paid to do, offer the constructive criticism in a non threatening way to the people who can institute change, and do NOT bad mouth a senior dev to your manager. Chances are they talk anyways, so if you can share your concerns in a manner that others can hear (no judgements or expectations of a "fix" even your share) you'll be in a great position to build trust and be seen as someone who is committed to the team.
Don't be attached to a solution. Be attached to the positive outcome, however that looks, even if the time-line or path doesn't line up exactly with your expectations.
This is a great way to put it. The company doesn't pay programmers to build software, they pay programmers to fulfill business needs.. and if they found a 'programmer' that could do it even faster with an army of trained pigeons they'd be completely satisfied with that. I think a lot of software developers miss the forest for the trees.
At this point I wouldn't even write the email. It sounds like there have already been far too many conversations on the topic, the only good step left is to just drop it completely, other than maybe a "I was thinking about it and I realized you were right" conversation.
I wasn't planning on bad mouthing anybody, that's a quick way to lose my job when I'm in a two-man team. The idea of going to his boss doesn't sit well with me, at least not about the technologies.
I'm going to speak to my boss and just make sure that we're on the same page about the role, and if they want to do the project the best way or the fastest way. Knowing businesses with an in-house dev team, they'll want it the fastest.