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?
Long-time PHP dev here with 25 years of experience. The unwillingness of your lead dev to consider tools better-suited to the task is going to be a problem. I know you don’t want to bounce so soon but things are going to get painful as all the friction from ignoring tools that Laravel wants is gonna start a metaphorical fire.
Good luck.
Thanks very much for commenting.
@grmpyprogrammer @Crunkle_Foreskin I think “this is called senior dev” is unwilling, maybe not the lead developer per se.
My reply in 4 parts:
(1/4)
- You don’t work “under a senior dev” or “architect”. You should just remove that junior label now. And you are a senior as well. In fact, every developer should also be an architect.
- Then you are 100% right, OpenAPI or something simular is the way to go. I hope you have more developers in your team you can talk to about this solution direction and WoW.
- That whole composer story is definitely a clear situation you are the senior.
@Crunkle_Foreskin
(2/4)So that being said. I think something else is also going on, communication and relationship. I bet he is actually a bit afraid of you doing (too) good and being successful at your job. So then this “senior guy” might think it he doesn’t come across well.
My advice here is to try to first repair the relationship with him, talk with him at the coffee about other stuff. Maybe you have hobbies in common?
@Crunkle_Foreskin
(3/4)Then next you really want to involve more people at this stage, ideally 4 or 5 team members should be on-board in order to brainstorm together.
Most importantly, try to not push your changes, this person seems a bit unable to cope with change (I hope he is not too old :P?). Another approach is “pull management”; try to make him curious about the topics, be positive and praise others where applicable, focus on the strengths of the developers, support each other.
Thanks for your points, there’s some really valuable stuff here.
I’d say he’s in his early 40s, and I try not to be ageist since I’ve had some outstanding older developers that I’ve worked with, but I think he’s perhaps stuck in his ways a little bit.
Unfortunately, it’s just me and him which are building this new API with no other developer involvement. So it’s kind of like a “he said, he said” scenario. Another unfortunate to pile on top of that is that we don’t work in Agile sprints (I’ve worked that for the past 4 years so it’s quite a change for me), so I only speak to the other developers once every 1 - 2 weeks. The only daily contact I have is the “Senior” who is in charge of this specific Laravel project.
I love the idea about sitting with him and talking. At first, he seemed quite cold to me. It warmed up a bit last week but now it’s back to cold, so I’m not sure if I just caught him on a good or bad day, or if I’d said something to upset him.
He was pretty firm about not doing either the OpenAPI or Composer things today, I tried to push a little bit, politely, and just say in the nicest way I could that Google Docs wasn’t the best fit for what we needed and that we’d probably be doubling-up on our work in future. He seems very focused on the time the project will take, and it feels like he sees any suggestions as a burden.
@Crunkle_Foreskin yea I notice this behavior very well. It’s not placement. In fact, very frustrating.
Maybe he is very busy, and doing all kind of stuff as the same time. Causing to lose focus and patience.
Some chit-chat might work… You also can just ask him DIRECTLY: Do you want to share something with me? (maybe there are other things going on? Maybe even not work related)… Or: Why don’t you think my concerns are invalid? And/or: Should I change my communication with you?..
I’m from the UK, so that might explain why I’m a bit hesitant to get confrontational. I’m still on my probation period so I don’t want to annoy and lose my role.
I like that, I think it might do some good to level with him and just ask those questions outright. I might see if I can muster up the courage to do that tomorrow morning.
@Crunkle_Foreskin I first thought US actually, since they also have a cultural hierarchy. I never worked in the UK, but maybe this same kind of hierarchy exists in UK workforce as well?
Anyway, I’m from The Netherlands. And often the Dutch are very direct. Ask direct questions. Speak-up. Etc. Of course it also depends on the person, people who are very shy quickly remain silent.
I understand you are also afraid to lose your job if you are still in your probation period.
Company is about 1000 - 3000, with a dev team of about 9.
The probation period is my main worry. The project hinges a lot on me and him working well together, so I don’t want to make that not work, or make it struggle.
There’s usually a pretty solid hierarchy in UK companies, at least from a development side. You have the Junior - Mid-Level - Senior progression. It was the same at my last place (I was actually a Senior on the job role) where you have Juniors under the Mid-Level and Mid-Level under the Senior.
I always listened to other developers though, I saw the role less as a “I’m the boss” position and just that I have more responsibility for what I’m doing. If I didn’t listen to some of the Juniors (who haven’t had the time to gain some bad habits :) ), a lot of good things would have been missed.
@Crunkle_Foreskin can I ask how big the company is? Is it like 50 employees…? Or 150? Or 15000?
He is technically higher than me on the job, as a supervisor, so it feels quite difficult to go to him and say: “Well, I think you’re wrong.”. I know it shouldn’t be difficult, but that type of conflict just isn’t something that’s common to me.
@Crunkle_Foreskin
(4/4)
Finally, depending on your personality and his personality this might be an endless battle. Since you can’t change personalities.
However, I hope everything will eventually settle a bit. And you can find a middle ground.It also depends on the company (low and high) management and the corporate culture, whether speaking-up is embraced or not. Or whether there are meeting about improvements and retrospectives.
@Crunkle_Foreskin Thanks for following me. I also have a kbin account btw.
https://kbin.melroy.org/u/melroy (@melroy@kbin.melroy.org), if you wish to follow me as well on kbin. Sorry I replied from Mastodon. I’m also a developer of kbin.
…why 4 parts…?
@Crunkle_Foreskin Sorry you said you are remote… Plan a INFORM meeting with him. Call it ‘coffee meeting’ or something. He will get it ;).
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?
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”.
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”.
My 2 cents…
You seem to have a money and career balance issue. Some jobs pay really well, but make you eat shit. (Done do not.)
If you sit tight, what are the chances the Senior bounces?
Can you add a side project to keep up to date on newer technologies?
If you apply to jobs before quitting, then the new company is already okay with your tenure. You will likely be stuck there, though for an extended time.
You cannot win this argument easily. The Senior will not see the error of their ways. If the Senior is overruled and knows you did it, you will be a target. Build lots of allies and be ready with alternatives when things fail.
My advice, sit tight. Enjoy the salary. Use side projects for skills. Look and wait for another opportunity. Build other skills.
@MNByChoice @Crunkle_Foreskin I fully agree, but the thing is… In each company you might encounter such a developer at least once… :)
I don’t have a career and money balance issue, this is the first role where a scenario like this has cropped up and it’s so…odd to me.
When I was a senior at the last company, I listened to absolutely everything and always had the idea in my head: “what if I’m wrong?”.
Pick your battles. If you jump on everything that’s wrong you’ll be continually arguing and never getting anything done. You need the relationship to be good enough that when you do go against him he’ll like you enough to listen and that can’t happen if every time you open your mouth it’s a fight. You will also want a positive reference when you inevitably leave.
Often the way things are in the code is a result of organizational problems that you are powerless to solve. Ignoring progress and changes for 10 years is quite a feat (composer was released 11 years ago) and to accomplish that that the senior dev must have established a power base in the company through relationships or reputation and chances are that you will not dislodge him (You’re not trying to dislodge him but that’s how he will be feeling). He’s probably defeated people like you multiple times over the years. You’re not just up against him, you’re up against everything and everyone in the company that allows him to be the way he is. Fixing that is well beyond your pay grade.
Learn what you can, enjoy the money, always be looking for your next gig.
The thing I worry about is the salary and job responsibilities. The interview for the role was completely different from what I am now doing.
It was advertised as a modernization role, and now I’m just a web developer. Do they expect the interview or the current position?
The Senior doesn’t really know Laravel or any advanced patterns that I’d expect a mid level developer to know.
The interview for the role was completely different from what I am now doing.
Isn’t that the norm? Like the old joke about hell seeming to be an all-out vacation, and then it turns out that was just the marketing brochure?
I very recently landed a sweet-sounding well-paying job at a large international consulting house. Turns out, on the inside it’s all gaffer tape and leaky abstractions. Not some of it, all of it. After having spent a few months sussing out the scope of the issues I determined that yes, this is unfixable by any one new hire, so I’ve done some interviews and will be starting a new position elsewhere presently.
Good luck with your new place.
Update: spoke to the Head Dev this morning and made sure I knew what my position was, so it’s definitely prioritising the project’s speed first.
Then spoke with the Senior in question and apologised for any friction, and suggested we do a debrief after the first phase of development and go back and smooth things over.
All went well! Thanks for your thoughts everyone.
TL;DR I would leave him alone regarding his software components.
I just finished writing this comment and noticed it’s your boss. I assumed you were the boss, bit maybe this comment still helps you.
Some people can’t be convinced. (Even if they can, they can be too busy to learn new stuff.)
There’s ideal and reality. I find this often discussed in software architecture books. As you’ve been doing, a good architect analyzes how the ideal proposal works in practice. In your case, your colleague is refusing the ideal either because he has a good understanding of the reality or it’s outside of his comfort zone.
I’ve tried several times to convince this kind of person. They either couldn’t act on what was told or intentionally ignored me. One guy even harassed me, which was his technique to get his way.
In any case, to work with this kind of person I learned to leave them alone. I let them create a blackbox and isolate my code / role from theirs as much as possible. I also try assigning a different but suitable role for them.
Regarding Google Docs… maybe assign a different person to do that for you.
I think intentionally picking the wrong solution makes you an irresponsible developer. Not only are you introducing technical debt immediately but slowing down your future progress.
But, you’re probably right about leaving him alone and letting him own these problems. I’ve suggested OpenAPI, he picked Google Docs. I’ll be there when we have to spend a few days rewriting the specs in OpenAPI.
Agreed. Some people will never attempt the ideal solution, and a pragmatic solution might be a good one.
