Upper management wants feature X. I propose architectures A, B and C, with C being my last choice due to its crudeness and unnecessary complexity. (But my manager and a manager one level above him had originally suggested it.) The senior coworker and the manager two levels above us pick C during their architecture review, despite my objections. I later find that they didn't even read the architecture doc I wrote, until weeks later. I spend 4 months building C, meanwhile telling my manager we could have built A or B much faster. I spend all of this time very precisely and sometimes unnecessarily matching the product specs, per my manager's repeated requests. Meanwhile, this senior dev and his manager constantly block my pull requests on gratuitous and unnecessary grounds, demanding repeated rewrites of production-ready code to meet arbitrary standards that haven't been documented anywhere and aren't at all reflected in production code. This has no purpose besides slowing down my (and my team's) delivery, in order to make theirs look better. (Teams and devs are evaluated and stack ranked based on quality, timeliness and delivery at Bloomberg.) I also agree to the expansions of functionality that they propose. As we approach release, my coworker quickly builds a prototype of architecture A and calls my implementation of C buggy and crap, without mentioning that he had insisted I build it. (In fact, it had exactly 2 minor bugs that product was considering never fixing.) He demos A to product, which doesn't at all match their vision that I spent months building, since he removes tons of its features, including extras proposed by reviewers on his team (which I obliged). Product seems happy with his implementation. Meanwhile, I just spent months building something that probably won't go to prod, while exactingly meeting product's and my manager's expectations. Undoubtedly this will be reflected in my and my manager's evaluations, negatively impacting our raises. How do I salvage my evaluation for this year? I've worked very hard on this and it's all gone to waste. Meanwhile, the other dev takes credit for my architecture and disses the implementation he insisted I build, not even consulting me or involving me with building it. He has been a darling of upper management for years. LC and GTFO is a copout for those who will never rise above being a senior dev, so don't mention it even though obviously I'll do it eventually.
Go back in time, write design docs, get sign off, profit.
You can't win against this. Change teams or better yet LC and GTFO
Considering the former, although neither option fixes my evaluation and raise for the year
What's done is done. You can't go back in time to do something to change your eval/raise Cut your losses and write off your current team/situation and find what's the best new path for you
Happens all the time, meet personally to your boss and his boss and seek some clarification. Mostly everyone has a rational and bias for everything .. whatever you do resolve this faster or move on ..
What's your advice on talking to my skip level manager about it? Don't want to throw my manager under the bus or seem like I'm bringing problems to my skip without any solution
With conversation you may be able to see from their perspective , if you skip it you have given them a free pass to do it to you again.
Next time, you should own your approach and implementation. You can take their advice as input but you should assert that you will own what you write, since you will be accountable for those deliverables. Don’t let other teams or “seniors” dictate bad design to you. It also seems like the senior guy quickly prototyped an MVP. This is probably what you should’ve done, because you said he also chose C (which you said would be a bad design? I was a little confused by this), yet he got done with a prototype quickly and showed it to product. Perhaps their team felt you were taking too long. Did you communicate it would take 4 months? Either way, you should’ve developed an initial MVP, showed that to product, gotten feedback, then iterated on that, rather than developing the feature-full version from the get-go.
For the current situation, talk to your boss and strategize what to do next. Be on the same team as him/her.
MAJOR typo that I just fixed: the senior dev built A, not C. No way he could have quickly built C, and that's the whole point that I have no way of proving
Tell them A architecture is worst, and you prefer C. They will give you A :D
Pointed out all flaws in A that I could find, which I proposed initially and he built. But it's still obviously the better architecture.
If you believe in your solution A them you should have fought for it. No matter what. That is what a,leadership is, however junior you are. Now take this as a life lesson and move on, focus on next project or next company prep.
Next time follow Cunningham's law :) Give them C and say that it maybe the right thing and do you see any flaws in it. They will then give you A
I will be very honest with you. You are still a bit far from being a senior engineer. 1. Propose what you think is the right and prepare questions for the alternative but bad choices. Why did you even bother propose something you don’t believe in? A or B? There should only be one design. If you think both can work, you haven’t spent enough time to compare the trade-offs between the two. Meanwhile, this also shows you are so difficult to coach. Have you truly understood C and deep enough to layout all the drawbacks so simple that everyone can get? 2. If you disagree with your team. You should stand behind your design and defend it. Regardless how strongly the senior member disagrees. You spent way more time on the topic than the rest of your team. For some reason, you did not put enough evidence to help your team to pick the right choice. That’s your failure because you are the owner. You are the one to bring every one on the same page. 3. Sign off and commit. You compromised but still disagrees and bringing up A and B after the fact. Why? It is the worst thing to do. You are either convinced or the team is convinced. Even if you disagree, you and your team are committed already! Bringing up the other possible designs after the sign off is such a red flag! No one would listen to you, why would they! 4. Bring everyone on the same page! Not only in the design phase but also in the code review phase. This requires not only a crystal clear design but also people skills. You should not surprise your team with implementation in merge request you never discussed with your team. If time is a factor, do your estimate and reason with your team why you cannot address X now because Y and Z is more important. No one wants to throw you under the bus. But you need to be transparent at the first place! 5. You own your design but you need to make it happen first. If you are not able to make it happen in X amount of time. Some one will, otherwise your team fails. Does that mean they own your work? No, they just wanted to save the team. If you made it happen, they would not spend the duplicated effort to repeat your work. They can not fully implement the features for sure but they want to help the team to get more support by demoing the basics of your system. 6. Don’t make yourself a victim. If someone in a working environment can make you a victim, most likely, that person is yourself. 7. You want to argue with me. Save your energy and think. Keep this post and revisit after you become a senior engineer. You are welcome. 8. Your manager/team gave you such a big opportunity. If you made it, you would probably be on track for promotion. Unfortunately, you missed it and you still don’t see it.
I want to print this out and put it on my desk
This is the kind of important stuff that no one ever tells you. Anything else I should know that I'd prefer not to learn by experience? And btw, I only documented C because my manager (and the manager above him in the architecture review) had suggested it. I had started building it, and didn't think it was the right implementation. Anyway, what is the correct extent of disagreement? I was afraid to disagree too vehemently about the chosen design for fear of not aligning with management, and that bit me in the ass hard. However, if I had been too vehement in my disagreement, that might have been a problem and I might have been labeled difficult to work with. Being too critical and disagreeing too insistently has been a problem for me in the past. What is the correct middle ground?
Every part of this, from not pushing a clear technical vision, to letting product put you into box checking mode, to rejecting review notes because they 'weren't documented'(???), to claiming that the bugs in your product were find because product said so, exemplifies a lack of ownership of your work. There are engineering jobs where people check boxes without any professional agency, but they don't pay that well. Either find one or do better
Tech Industry
Yesterday
2737
Go woke, go broke: Google fires 28 employees involved in pro-Hamas protest
Tech Industry
Yesterday
345
Chances of meta clearing E5 with screwing up one coding one round and acing all other
2024 Presidential Election
Yesterday
1447
Biden ruined America and tech! Tax plans are insane
Layoffs
4d
19758
Hearing rumblings of incoming layoffs at Apple?! 🫡
Tech Industry
Yesterday
1007
Sick VP about to be Thought a Lesson
Banging your head against a political wall won't help you rise above being a senior dev either
So what do I do: nothing? You're not offering any solution here.
You need to play the game and beat them