Seeking advice as a Frontend web developer
We have this big project at work...an "all hands on deck" kinda thing that has us rank-and-file frontend devs working alongside our manager more closely than I'm used to. And it was fine, because I like the guy and he's been a decent manager. But this project is killing me.
On multiple occasions now I've written code, had it pass code review (often with his approval after a round of changes/guidance), and then every few days we get these massive re-write PRs from him where he completely rewrites large chunks of what we've done. It's leaving me feeling a few different ways:
- Angry because how quickly your code gets replaced is a (imo, bullshit) metric used as a part of our annual reviews and promotion discussions
- Doubting myself because in my head a good developer doesn't have their code rewritten that quickly.
- Confused because features I thought I understood are constantly being rewritten leaving me wasting time trying to relearn how things work
- Wondering what the point of writing code is if it's just going to be thrown in the garbage later in the week?
And like I'll be the first to admit I'm not the most proficient developer on our team. React and Typescript are relatively new concepts to me, despite a long career in web development. But I've been writing with it for about a year now and I had thought I was finally getting a good grasp on things. But now I'm wondering if I'm just an idiot? Is it imposter syndrome or have I actually somehow coasted through a 15 year career across various stacks and it's just now catching up to me?
Or is this just the nature of massive projects like this? We had a half-baked product scope to begin with and its getting daily changes with entire chunks of it not very well thought out by our PM. I can see how it would make sense that the more senior developer might see the need to refactor things when things are constantly changing and we're left writing code based on assumptions and half-written requirements. I'm also getting are comments on my PRs that request changes, but mid-comment he's like "I'll just take care of this because it's blocking me".
It's just really taking a toll on my mental health and how I feel about my job. I've been trying to find another job for a few months now, but I'm not having any luck. Job hunting sucks and when you're already demoralized as hell, it's hard to sell yourself to prospective employers.
Could really use some insight from other experienced devs, please!
Clearly this is a dysfunctional team. If your manager was better they’d find work for you that wouldn’t be so demoralizing. They should understand that churning over your code after it’s supposedly reviewed and approved is the wrong approach. I’m going to assume that you aren’t producing the best code on the team because of your lack of experience with the technology. But they hired you for a reason and should be able to find stuff for you to be effective on.
I would have a discussion with your manager. Don’t be aggressive, but the theme of the conversation should be that you aren’t being guided to the right work (which is implicitly their job). Let them know how you feel. Don’t make your feelings the responsibility of your manager, but focus on how clearly the money spent on you is being wasted if your deliverables are frequently overwritten. So its in the interest in the company to find tasks you can accomplish with the standard code review process.
This all assumes your manager is acting in good faith. It’s possible they are sabotaging the team in a failed attempt to pump their ego and appear important to upper management. In that case I would look to switch teams or jobs ASAP.
It's refreshing to have a conversation with you that didn't start with you magically appearing before me in Minecraft ;)
Yeah I'm trying to build up the courage to do that. We have our 1:1's on Tuesdays, so I guess I have the weekend to put all of my thoughts into more work-friendly words. I just don't want to word vomit or like you said, make my feelings his responsibility.
I think he's generally acting in good faith and I've long felt that a lot of our problems begin just above him in the corporate ladder (middle management...who would've thought!). He could just have me fooled, but despite recent problems I still give him the benefit of the doubt.
To be fair your feelings are a little bit his responsibility. Like if something is making you miserable and more likely to quit that's relevant to his interests and he should adjust his behavior. But generally your approach should be to talk in terms of direct business interests.
I think as long as you're not being rude you shouldn't worry as much as most people do about "work-friendly words".
Write notes! There's no glory to keeping everything in your head :)
I've never worked as a dev, but I have done some coding for personal projects. I don't have any advice. But that metric of how quickly your code gets replaced sounds like the most bullshit metric I have ever heard of a company using. Far worse than lines of code, and that is also a terrible metric.
Yeah most code-based metrics are terrible. We don't pay attention to lines of code, but number of commits or coding days (at least 1 commit per day = a coding day), which also doesn't really pan out either because there are genuinely days where you don't commit any code to the repo. So of course people find workarounds, like getting really loose with what's commit-worthy. My workaround is simply maintaining our testing server's branch so it's caught up to master, plus whatever feature work's going on. It's dumb.
It sounds like they don’t know how to manage a team of developers. If managers there were more competent and trusted by upper management then everyone would simply know if developers are working or not.
Goodhart’s law in action:
It discourages code deletion. That means the codebase is highly likely to have a bunch of bloat that's never even used.
I'm guessing your manager is a former engineer?
In my experience (partly personally, though hopefully I was never as bad as your manager), this usually happens because the manager gets pressure from above about deliverables, and their options for doing anything about it are all bad:
The right answer is something like strategically pushing back on pressure (managing expectations, collecting metrics to tell the desired story) and prioritizing ruthlessly, but that's hard (not just emotionally challenging, but difficult to execute effectively) and requires an assumption of good faith from above, and promoted senior engineers have a very tempting alternative:
Let me tell you: as that manager, sitting there with deadlines looming and just knowing, instinctively (because "promoted from IC" generally requires being a talented IC), how to implement a bunch of stuff in the backlog, that option is extremely appealing!
Now, I would argue that's not inherently a bad thing to do, but there's definitely a right way to do it (namely: follow the process for IC work), which your manager is definitely not doing. Getting lots of your code rewritten in short order is not normal or appropriate: if there were something wrong with your code, your manager should be talking to you about it (or at least not rubber-stamping it in code reviews!), and if there's not, then they're not appropriately focusing their efforts.
The thing to do here—with a major caveat—is to talk to your manager, and if they don't seem to recognize the issue or are unable to address it, talk to their manager. The caveat, of course, is that (as @teaearlgraycold mentioned) you have to trust your manager and grandmanager for this to be reasonable, and my experience has been that that sort of trust is pretty uncommon in the typical corporate environment. But if you do trust your manager and grandmanager, this is definitely the way to go.
If you don't have that sort of trust, unfortunately the only real options are to soldier on or leave. For whatever it's worth, the situation you've described does not sound like a negative reflection on your coding abilities.
I touched on this in another reply, but I initially liked him being a manager that wrote a lot of code because I felt it helped bridge the gap between IC and manager. But yeah it's clearly not always sunshine and rainbows and now I'm rethinking whether it's really doing me any good at all.
That's what's so confusing and frustrating about this to me. My annual reviews are good (not great, but good enough to get a decent bonus) and the only direct negative feedback I've gotten is that I don't write code fast enough. Which is a valid criticism, but a far cry from meaning it needs to be repeatedly rewritten.
Some context - I am a former developer who has been managing for almost three years. I still get to write a good amount of code but a lot of the things I work on at work are small pet projects that are "nice to haves" for the org - not contributing to our bigger projects. For those, I act more like a manager and, well, manage the development of the project.
Poor upfront planning for a project can be its death knell. So many projects I have managed have been delivered, albeit late. This is almost entirely due to my lack of planning and understanding scope before we even start the work. The plus side though is that as the manager I have to ability to bring this to attention to the General Manager and stakeholder and re-assess what is actually required for the project. I think it would be really beneficial to take a day and rescope the requirements of the project as a team, with the stakeholders. Taking a day to refocus, reprioritize, and come up with new deadlines is a benefit to everyone involved and almost always worth doing. Now the tricky part in your position is convincing your manager this is what the team needs to do.
Your manager should stop getting their hands in the code as well, and let the team (you) work on delivering features. If they are a good developer, they should be instrumental in the reviews, sign off on changes, and take ownership when presenting the changes to the stakeholders for the project. When changes to what they signed off on are needed, the work needs to be funneled back down to the team. Its hard to manage and code at the same time - trust me I have been there.
If they really need to write code, they need to act like a team member and talk about the changes that they are going to make with the team. This means you (or your colleagues) aren't going to get blindsided by PR's that completely rewrite and change what you already did. This is not fair to you or your team.
You are not the problem, mismanagement of people, and project deliverables, sounds like the problem.
As for metrics, these sound absolutely useless to how productive actual developers are. I would never use something like that myself - especially since in your case it sounds like its your manager who is changing your code? That's setting you up for failure and that's what bad managers do.
TLDR: manager needs to manage, not code; or stop coding with impunity. Your team needs to have the long hard rescoping and planning meetings that should have been done at the start of the project.
Before this project, I liked that he was a regular contributor to the codebase. It was one of the things I respected most about him because I've had a lot of managers in the past who either didn't know how to write code or simply didn't. So it was kind of refreshing because it eliminated the disconnect between management and the developers. But yeah this project has shown me that there is absolutely a big downside to that as well!
Yes! Absolutely. Hearing my code is flawed stings a little, but it helps shape me into a better developer in the long-run. This wouldn't bother me so much if we were hearing "hey we did what we needed to do to reach a milestone in a messy project, now we need to clean it up, here's how I did that". But it's just... "hey I refactored a bunch of stuff, here's the PR". I guess it could be worse, he could just bypass the PR process entirely...
It's not something implemented by my manager, and he seems to know it's bullshit. It's something implemented by our CTO, who has a long career in upper management for various FAANG and FAANG-like companies.
I am sorry to hear that the CTO does not understand developer productivity and how nuanced it really is. It sounds like this project is just a mess and someone in a higher pay-grade than you needs to actually do something about it.
I would recommend to keep bringing this stuff up with your teammates and manager, keep doing your best work, and ask for clarification on things when they change.
I’m not sure what the culture is like at your company, but typically managers don’t get involved in day to day software development in my experience. Further, getting them involved is necessarily a waste: they’re being paid (probably better than you) to talk to other people, groom backlogs, write reports, etc. and when they take time out to write code, they’re neglecting their other tasks.
If it’s more of a tech lead position than a manager, then rewriting your code every few days is a waste of time and should reflect as much on their performance reports: ideally we’d all write as few lines of code as possible, once, as fast as possible. This sounds like the literal opposite of that.
Lots of others have said many good things. I'll just add this:
Whoever is rewriting large portions of your committed code should be communicating why it's being rewritten, at least on a case by case basis. Especially since it's regularly occurring, a more general explanation is warranted ("you keep doing X that way, when it should be done this way because:"). Since they're not communicating these things to you, consider proactively asking outright. The point is: it's happening; you don't know why; and it's having a negative impact on you.
If it were me, in the conversation, I would phrase it respectfully, professionally, and positively. I'd avoid being confrontational ("why are you doing this to my code?"), and instead turn it towards business interests, with wording such as "I've noticed that, recently, a lot of my code is being rewritten. I want to meet expectations, so I'd be interested to know the ways my code is regularly failing to meet those expectations."
As I write the above, it makes me think: When you see the diffs (changing from your implementation to theirs), are you able to see and understand from an objective, technical perspective what has improved? If this were happening to me, I would have opinions about their implementations, and, assuming their changes are also going through a PR process, I would comment right in the PRs, before their implementation gets approved and merged. I would talk about my approach vs theirs, and compare relative merits. (If something they've changed is actually better in a given case, I'll admit that; or at least, not object.)
If you're not already doing this on their PRs, is it because you don't see how a given change is an improvement, or because you don't want to engage?
Like others have said, you need to have a conversation. There may be a good reason, there may be a not great reason, or there might be no reason. But you don't know until you have the conversation. My advice would be to roll play the conversation and use a structure to help yourself communicate the issue that you're seeing.
"I'm concerned that you're refactoring a bunch of code which is normally not like you. I'm concerned about that because it makes me feel that my contributions aren't worthwhile or I'm missing the mark. Could we talk about that a bit?" might be a good opening. And I would think about what he might say and how you would respond to those responses. Get a friend to roll play it a bit with you that way it takes some of the pressure off the conversation.
Last bit of advice is to take a moment to hear what he says - so take deep breaths and be uncomfortable as you digest. I've been on a lot of manager-staff conversations where both people are talking but one or the other hears only what they want to hear emotionally. That's usually not a good conversation.
This is a late response, but I'll just point out that well-written, well-tested code is easier to rewrite, while code with few tests that's difficult to understand is hard to rewrite and tends to survive longer because people don't want to break it.
This is another way to say that how long code "survives" is a bad metric if not understood in context: why was the code rewritten? What new feature did this enable?
Ideally the commit message explains why a change was made, but often people skimp on them, so you have to ask.
I'd also ask how much does this metric really matters and how worried should you be if someone rewrote some code. It's certainly not something I'd want tracked if it leads to bad interactions between team members, where rewriting someone's code is screwing them over. I wouldn't want to have to think about that at all. You shouldn't have to care who originally wrote the code when you make an improvement.