Discussions with your boss



  • I work for a small company and as such report directly to the CTO. Now, the CTO is actually quite competent and skilled, yet every so often I get discussions like this which get frustrating really quickly.

    Every so often this happens, and it drives me nuts.

    CTO approaches my desk, interrupting me in the middle of something, and discusses whatever... eventually there's something that might warrant me going to my screen and demonstrating something to him, but whoops, because I was in the middle of something, things aren't working right.
    CTO: What's going on? The thing is broken.
    Me: I was just in the middle of stuff.
    CTO: What do you mean? Why is it broken?
    Me: Because... I was working on stuff.
    CTO: But it's broken.
    Me: Yes. Yes, it is. Because I'm in the middle of refactoring something.
    CTO: But why is it broken?
    Me: It's broken because I haven't finished what I'm working on yet!
    CTO: But it's a new feature. Why would an added feature break existing features?
    Me: Because... nevermind. I'll fix it by the end of the day.

    Assuming you have a "good" boss, what unusually cyclic, pointless, or PHB-like discussions have you had with your otherwise sane manager?



  • @The_Quiet_One said:

    Assuming you have a "good" boss

    I don't. Most discussions with him are pointless and/or result in me being more annoyed.



  • @The_Quiet_One said:

    CTO: But why is it broken?

    Oh, he's center field.



  • I have a good boss, but he's a Nazi about coding style, and some of his ideas of "good C# style" are pretty dumb.

    For example, your using statements should be inside the namespace, not outside the namespace.

    Why!?

    I guess if you ever put two namespaces in a single file that might make a slight amount of sense slightly? But then putting two namespaces in a single file would undoubtedly run afoul of his rules anyway.

    Anyway, now that I've shipped a couple features, he's relaxed the code reviews.



  • @blakeyrat said:

    For example, your using statements should be inside the namespace, not outside the namespace.

    I've actually seen this suggested before too. I can certainly see it making sense with multiple namespaces in a file, like you said. I assume that it comes from the development of .NET, where there's huge variation in coding styles. Someone probably thought it was a good idea back then and suggested it.

    And, well, there's not really a downside to doing it... but the only place I've ever seen it was when I was looking for an obscure bug and ended up on a Japanese coding blog about C#. (Once, my problem was so obscure, a post on 2ch was on the first page of my search results! I don't even know!)



  • @The_Quiet_One said:

    Why would an added feature break existing features?

    That's... kind of a valid question. Obviously a perfectly modular code is a Platonic ideal, but generally things from different parts of the app shouldn't break too badly.



  • There's also the argument that the build must never break, and that that should include tests passing.

    If you're truly refactoring, things should absolutely not break.



  • In a certain Korean corporation, discussions with Korean management (KM) look like this:

    KM: Urgent issue! Do [insert stupid shit] by the end of the day!
    Me: Maybe instead of [insert stupid shit] we should do [insert something reasonable]?
    KM: (get angry and literally stop talking to me for a month, because I responded in a non-obedient tone, but still require to carry on all tasks, which I don't know they exist, because the KM stopped talking to me)

    The sad part is, this is not exaggerated. A coworker after such incident, got stopped being called by name, but "[division name] member". At least he was being mentioned in emails.



  • Well he was showing things on his own PC, so I assume that wasn't a checked-in changeset.



  • I get this crap about once a month:

    Boss: Project X is your #1 priority, don't work on anything but Project X.
    Me: But yesterday, you told me "Project Y is your #1 priority, don't work on anything but Project Y." Which one should I work on first?
    Boss: Both.



  • @Magus said:

    If you're truly refactoring, things should absolutely not break.

    So...you can only paste in fully working / refactored code over previous code?



  • Yes, it was just a work-in-progress which was interrupted. And it was a very much related feature that I was adding onto, and as a result, to keep things DRY, I was factoring out the common functionality. Since everything I was working on was in the UI, any sort of bugs are going to become quite evident when one starts using it.

    It's kind of like if I were to go to a repair shop and ask why the radio won't work in the middle of the repair if all they are doing is switching out the battery.



  • @blakeyrat said:

    and some of his ideas of "good C# style" are pretty dumb.
    Someone's probably blindly running StyleCop and taking its warning of "oh noes! I'm using my own class instead of the built-in one! How will I ever discover this, or breathing?!" way too seriously.



  • @The_Quiet_One said:

    what unusually cyclic, pointless, or PHB-like discussions have you had with your otherwise sane manager?

    Boss: How long will it take to do <X>?
    Me: <Amount of time Y>.
    Boss: That's no good. Do it in <amount of time Z> instead.
    Me: It can't be done in <Z>.
    Boss: Do it in <Z> anyway.
    Epilogue: Does <X>, because of the natural order of the universe it takes <Y> instead of <Z>. Three months later, Boss reports "can't do estimates" on performance review.



  • @The_Quiet_One said:

    CTO: But it's a new feature. Why would an added feature break existing features?

    Because the new feature needs functionality which tightly couples it with old features unless I refactor.

    In other words, if I don't do this now, every new feature could break all old features.



  • @xaade said:

    Because the new feature needs functionality which tightly couples it with old features unless I refactor.

    Refactoring by definition does not change functionality. If you call something that can break code a 'refactor', you are using the wrong word.



  • I get:

    Me: We have X, Y and Z all of which need doing now - which one is actually most important?
    Boss: Which do you think is most important?

    🤦



  • Feature B uses module A
    New Feature C needs functionality D of module A called A:D. However A doesn't have a modular division between A and D.

    If C uses A as is, C will have to use an adapter if possible. If all that fails, someone may try to alter A to make D more directly exposed.

    Someone can attempt to refactor A to decouple D, but during that process B will be broken until the refactoring is complete.



  • @loopback0 said:

    Which do you think is most important?

    I pick the one that sounds the most fun / least painful.

    And then I eat my cookie before my sandwich..yes.



  • That's normally when you'd make a feature branch or not check in. You shouldn't check bad code into your main branch.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.