I've been working on some components in the last few days. I already asked for clarifications and we narrowed down the list of what's needed. Just when I'm finishing up the tests, the person I talked to removed half the crap from the list of requirements so I had to remove those from my code as well.

Wasted effort and what do you think the reviewer is gonna see? "It took you days and this is all you delivered?" Nevermind that, I can stop caring about that since I can defend myself. The annoying thing is I keep getting shit about not asking questions when I always did. It just happened that the person I talk to only realize certain things after a certain amount of time.

He is my team mate and I don't want to push him off the bridge since I know he's also struggling with some new tools. He's also apologetic about it. So I guess a better approach now is to collect all the test data even before development. If that doesn't work, well, fuck. Gotta put yourself first, right?

I'm annoyed but it's not worth the premature aging, at least not as much as the abundance of misspellings I had to deal with while working with other teams' codebase, so I'm just gonna think that I still get paid the same amount.

  • 6
    Just start off the bat with the reviewer "Yeah I know it doesn't look like X weeks work but half the requirements got taken off at the last minute, call Y if you want to know more about it"

    Work that doesn't ship isn't wasted. You learn by doing. Everything we do is either a challenge or a routine. The more you see routines the more you see how they can be automated away. The more you see challenges the better you get at solving new ones. Keep your chin up, it isn't as much of a loss as you think :)
  • 2
    @justamuslimguy or just show him the git history and all the red
  • 3
    Changing requirements is quite common.

    Make sure there is a log trail or e-mail conversations documenting it, and if you want to help your coworker make sure they keep a trail to.

    As @justsmuslimguy said, even things that does not get shipped might be worth it.

    Either there was external changes, an api or rule that changed, or you just found a better solution when everything was finished, and shipping code that is not required just opens up for moe bugs, especially if the code then sits unused for an extended period.

    I often throw a way thing on the way as I rework and refine things, removing parts that prove to be obsolete, even whole features, if we find customers really do not need them.

    And that is sometimes found only when done and testing the complete solution.

    Things that sounded very good at planing did not really work out in practice.
  • 3
    I don't really mind the requirement changes since I'm used to it and I understand why it happens. I'm just annoyed when my manager keeps insisting on communication problems as if it's my fault for not asking. The point is I already asked and it doesn't matter how many times I ask, requirements can still change a few days later and the answer to my previous questions will change as well.
  • 4
    @rutee07 That is bad :/

    When will companies learn that they save money by encouraging employees to avoid internal conflicts?

    And I know, that is a rhetorical question :( with rarely as answer.
  • 4
    I've had such moments when some defects were hard to understand and to find the cause, but in the end the fix was as simple as several lines of code, but overall process took days for analysis and tests.

    Previously I was worried about such thing but gradually accepted that complexity is not measured in lines of code.
  • 3
    @iiii so very true.

    And frankly, a one line fix is much easier to trust as its most likely a logic fix than actual code fix.
  • 1
    @iiii one recent example, a month long investigation into logout problems found it to be a race condition due to params in prod.

    No code change at all, just two numbers to change.

    Still it solved the problem :)

    But its not much of a review ;)
Add Comment