> The time tax is paid by not delivering a feature. Architecture is supposed to be there to help you, not fail deadlines.
Most deadlines are artificial. If it's not artificial, yeah, you're going to have to sacrifice something for the sake of the real deadline. But you are sacrificing something, and it's not just subjective fluff.
> Also, it seems you completely failed to read or get what I wrote. My point was that if a PR delivers a feature without defects then your team is far better off if you accept the PR and refactor later when you can spare the time
You don't ever have spare time. When you finish a feature there's another waiting for you. At least, that's how it works literally everywhere I've worked. Working this way is just another form of over-promising and under-delivering.
> then it is if you throw a hissy fit and refuse to get the feature done if you don't get your way
Rejecting a change doesn't mean you're throwing a hissy fit.
> You are paid to create value which is in delivering features and fixing bugs. Architecture is supposed to be there to help you.
It does help you. In the medium to longer term. In the short term, literally any standard out there will slow you down - unit tests, CI/CD, shit - testing at all. It all slows you down. It doesn't mean we should just code like its 90s era PHP - the fact that we don't should be a strong signal about the value of this whole hypothesis you have going here.
> You have to pass interfaces throughout a bunch of components, which require updating all sorts of tests, and result in a large code footprint.
Funny. Your tests are slowing you down, why don't you just comment them out to get your feature in?
> Look at what you're trying to claim. It's supposedly easy and trouble-free to put together a PR that respects your personal notion of what the software architecture should be.
It's not actually just personal. We have unit tests that enforce certain architectural rules.
> Yet, the work to refactor code that breaks it is so insurmountable that you're no longer able to refactor it back to shape?
If you don't do these things for the sake of feature velocity, as a senior software engineer, why should anyone else? If no one is, how large of a problem do you think you're going to get? And do you really think its just as easy to fix something after the fact?
Of course, if you don't know how something should be, that's one thing. But knowing how it should be and just skipping it altogether is quite another.
Why are you even refactoring for reasons you view as subjective? I don't do subjective refactorings. Despite what you claim, at the point of a change, much of this stuff is very not subjective. If you show any developer a function call before a feature was added, and what it looks like after its been hacked it in some fucked way, no one is going to say the fucked version is better.
> It looks like the FANG engineer you tried to badmouth had a firmer grasp on things and on what it matters the most than you do.
Well maybe you're just so smart its trivial for you to navigate this stuff. If so, continue by all means. Until then, us mere mortals will have to adopt standards so our codebases don't outpace our ability to understand it.
Most deadlines are artificial. If it's not artificial, yeah, you're going to have to sacrifice something for the sake of the real deadline. But you are sacrificing something, and it's not just subjective fluff.
> Also, it seems you completely failed to read or get what I wrote. My point was that if a PR delivers a feature without defects then your team is far better off if you accept the PR and refactor later when you can spare the time
You don't ever have spare time. When you finish a feature there's another waiting for you. At least, that's how it works literally everywhere I've worked. Working this way is just another form of over-promising and under-delivering.
> then it is if you throw a hissy fit and refuse to get the feature done if you don't get your way
Rejecting a change doesn't mean you're throwing a hissy fit.
> You are paid to create value which is in delivering features and fixing bugs. Architecture is supposed to be there to help you.
It does help you. In the medium to longer term. In the short term, literally any standard out there will slow you down - unit tests, CI/CD, shit - testing at all. It all slows you down. It doesn't mean we should just code like its 90s era PHP - the fact that we don't should be a strong signal about the value of this whole hypothesis you have going here.
> You have to pass interfaces throughout a bunch of components, which require updating all sorts of tests, and result in a large code footprint.
Funny. Your tests are slowing you down, why don't you just comment them out to get your feature in?
> Look at what you're trying to claim. It's supposedly easy and trouble-free to put together a PR that respects your personal notion of what the software architecture should be.
It's not actually just personal. We have unit tests that enforce certain architectural rules.
> Yet, the work to refactor code that breaks it is so insurmountable that you're no longer able to refactor it back to shape?
If you don't do these things for the sake of feature velocity, as a senior software engineer, why should anyone else? If no one is, how large of a problem do you think you're going to get? And do you really think its just as easy to fix something after the fact?
Of course, if you don't know how something should be, that's one thing. But knowing how it should be and just skipping it altogether is quite another.
Why are you even refactoring for reasons you view as subjective? I don't do subjective refactorings. Despite what you claim, at the point of a change, much of this stuff is very not subjective. If you show any developer a function call before a feature was added, and what it looks like after its been hacked it in some fucked way, no one is going to say the fucked version is better.
> It looks like the FANG engineer you tried to badmouth had a firmer grasp on things and on what it matters the most than you do.
Well maybe you're just so smart its trivial for you to navigate this stuff. If so, continue by all means. Until then, us mere mortals will have to adopt standards so our codebases don't outpace our ability to understand it.