6 ms·
Yes, this is common. Frankly it was a bad idea to complain; you should be prepared to... be invited to leave your current position. Here's why: Everyone (on th
by unanswered 5y ago
Yes, this is common. Frankly it was a bad idea to complain; you should be prepared to... be invited to leave your current position.
Here's why: Everyone (on the ground floor at least) knows that the code is terrible, but the organization is not optimizing for good code. Code quality is simply and literally a non-goal. The goal is to deliver Projects, where a Project is a unit of work which advances someone's career, whether it be an IC, a project/team lead, a project manager, etc. Now, it's okay not to internalize that goal for yourself; but you've exposed yourself as not understanding that this is the goal that everyone else has. Unfortunately, this makes you a liability w/r/t the goal.
There are ways to advance other goals in the organization, and I suspect these organizations only survive as long as sufficient people are doing just that, but they all revolve around making other goals coincide with The Goal described above.
Note that The Goal isn't a secret or taboo; it's explicitly acknowledged in some organizations. Not so long ago at Microsoft, for example, it is known as "impact" and is the explicit top-level metric for performance review. If you can figure out how The Goal it's expressed in your organization, you can attempt to rescue the situation by explaining that what you really meant was you want to advance The Goal (eg. "improve my impact") by delivering improved code quality in future projects which will have such-and-such an impact on visible metrics.
- jmole 5y agoIt really boils down to this: if it ain’t broke, don’t fix it. If it is broken, and no one else seems to see that it’s broken, then it’s your job to convince everyone else that it’s broken so that “fixing it” becomes part of the The Goal.
- Aqueous 5y agoThough this can also backfire. I observed a huge architecture error in the central data structure / schema of our system. Everyone agreed that it was a huge problem so I got put in charge of fixing it. Of course when you build an entire system around a bad schema, it gets baked through every inch of that system. Over a year later and it’s mostly fixed, but my career has stalled and I took the major hit to fix it.
- siproprio 5y ago"Projects" are "something that advances someone's career"? I thought projects were "something which our client actually paid for and we're contractually obligated to fullfil"
- yen223 5y agoA bit of A, a bit of B. Successfully delivering a project that generates a lot of revenue is a great way to advance one's career.
- quickthrower2 5y agoProbably not for FAANG who tend to not have clients with custom contracts in general. Unless you are going to spend 20bn a year with Google I don’t think they care about you enough for a special contract with deliverables.
- throwaway_fred 5y agoThis resonates, I also suggested that I might not be a good fit as I dont think the result impact is there. This was probably not good career move here, as it is being discussed higher up. But I honestly am unable to create impact with this codebase. This could also just mean that I am not fit for the job and they need other people. I do understand the goal tho, that's why I raised the issue that I cant deliver enough impact in my eyes. And I think it's the right thing to raise. Thanks for your reply, it now makes sense that quality is not a goal. At my level I should be able to work with this instead of just complaining.
- Sevii 5y agoFAANG wants people who can 'get things done' in the byzantine code bases that they maintain. That is why they pay so much and why turnover is so high. Fundamentally fixing the problem is not necessarily possible. At FAANG basic things like maybe upgrading from Java 8 to Java 11 are three year 50 person projects.
- tdeck 5y agoIt's also very possible that you'd be happier and more effective on a different team at the same company. All of these companies are big enough to have a great diversity of systems, from nascent projects to polished but boring workhorses, to unmaintained balls of tech debt that they can't turn off but nobody wants to work in. Often if you want to influence the direction of a codebase, it's best to get in on a new project or system that's just being built.