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?

    :facepalm:



  • 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.



  • @actual quote from a former supervisor said:

    They're all priorities.

    @my response said:

    "Priority" means "that which comes before". Multiple things cannot come before each other...

    Since we're in a time crunch, I need to know, if I'm going to be late on something, which is the least problematic for me to be late on?

    @the verdict said:

    You can't be late on any of them [no matter how far up we move the deadline and how much more we put on your plate]

    Yeah, I quit. I was told on the way out that I'm arrogant for contradicting people in this way. Then I really dropped some contrarianism/arrogance:

    I didn't contradict them. I was just pointing out that they were contradicting themselves. I though they might want to know.


  • @Bort said:

    Since we're in a time crunch, I need to know, if I'm going to be late on something, which it the least problematic for me to be late on?

    I take a different forcing approach and pick using my preference and ask if there's a problem with that (assuming no other direction).

    @Bort said:

    I didn't contradict them. I was just pointing out that they were contradicting themselves. I though they might want to know.

    +�



  • @boomzilla said:

    I eat my cookie before my sandwich

    Some people just want to watch the world burn.


  • :belt_onion:

    @NedFodder said:

    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.

    I get something similar to this, but my boss is great and not insane, so when he says "Both" he quite literally makes the :trollface:. The newest #1 is the #1 to work on, and then fall back through the #1 stack in LIFO order.



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

    I suggest you re-read the OP. The CTO visited my desk, and what was on my screen was my unchecked code because I was in the middle of something. I hadn't checked it in precisely because it was bad code, and I knew it was. I was hoping it was at least workable to the point I could have shown what I wanted to demonstrate at that moment, but alas it wasn't. The CTO eventually understood, but it took a lengthy and frustrating back and forth of, to summarize, "why doesn't your partially finished code work?" followed by "because it's partially finished"



  • @NedFodder said:

    Boss: Both.

    I heard/read/don't-remember that someone created a list on their board. So when something got bumped, it became very obvious what else was impacted. Understanding ensued. Open floor layouts make that harder - no boards. Except the communal walls...



  • I'm in that hell right now. Project A should have been done months ago (read my PHP + Angular post) and just today I started on Project B. For project B we have 6 weeks for 2 fulltime devs, but instead what I got was 0.5. Now I"m 80% project B, 20% for project C and 60% project A.

    Not to mention that my boss doesn't act like it so I get tossed around by the PMs which delegate all their shit on me.



  • We've got a backlog for that. Which reminds me of an email discussion I had this afternoon. Context: Tomorrow's a national holiday.

    PM: Do we need to have the meeting today nobody's in.
    Me: I don't think so, everything at the top of the list needs <person who isn't in today>
    PM: I do want the top two items clarified.
    Me: (list changed) OK, <top item> I can explain, and <second item> <person who is also in> can do.
    PM: nonono you're looking at the wrong list
    Person who is out today: Let's move the meeting.

    Not sure who the :wtf: was there, but I don't get why the PM doesn't just copy the jira issue numbers instead of going 'top two in the list' while knowing we use a different list by default.



  • @PleegWat said:

    Tomorrow's a national holiday.

    Viva el Cinco de Mayo!



  • Liberation day - 70 years since the end of World War 2.



  • @The_Quiet_One said:

    The CTO visited my desk, and what was on my screen was my unchecked code because I was in the middle of something.

    Years ago (at the dawn of the virtualization age), I adopted a technique of keeping a stable running copy of code on my machine along with the "work in progress". It was for my own sanity, but it does avoid this particular issue as a side effect.


  • :belt_onion:

    git stash / svn copy or equivalents should be good enough for that, no?



  • @Eldelshell said:

    Now I"m 80% project B, 20% for project C and 60% project A.

    Sounds like that "Common Core" math I keep hearing about.



  • @Onyx said:

    git stash / svn copy or equivalents should be good enough for that, no?

    Depending on your project, perhaps only if you like waiting for 20+ minute compiles...



  • The stash thread is :arrow_up_down: :repeat_one: :arrow_heading_down: :rewind: that way.


  • Winner of the 2016 Presidential Election

    I think he was demo-ing the actual broken code though (as a "Hey it's a WIP but here's what it will do" type thing). So even that wouldn't help :)


  • Discourse touched me in a no-no place

    @loopback0 said:

    Which do you think is most important?

    "Me": "That's above my pay grade."


  • Discourse touched me in a no-no place

    @The_Quiet_One said:

    The CTO eventually understood, but it took a lengthy and frustrating back and forth of, to summarize, "why doesn't your partially finished code work?" followed by "because it's partially finished"

    "You wouldn't expect a partially-built house, where they hadn't put the roof on, to keep out rain, would you? This is like that."



  • @da_Doctah said:

    Boss: How long will it take to do <X>?

    I once had a boss that did something similar. I called it the "Dating Game" because the objective was to get you to say the date he had in mind..

    Boss: When can you finish project X?
    Me [doing a quick calculation based on 640 hour estimate]: I should be able to have it done by May 1.
    Boss: What about if I assign another resource to the project?
    Me: Well, then, we should be able to finish by March 1.
    Boss: What about if I assign two additional resources to the project?
    Me: Well, then it should be done by February 10th or so.
    Boss: Great! Let's get going.

    Of course there will be no additional resources; you will be slaving by yourself. And, inevitably:

    Boss: But you promised me this would be done by February 10th?!
    Hapless programmer (other people, I never actually had the nerve to do this.): Well, you promised me two additional resources.
    Boss: I don't remember that. I remember you were going to work on it, and promised to have it done by February 10th.


  • Grade A Premium Asshole

    There are a lot of shitty supervisors in the world.


  • sockdevs

    And that is why you always get those things fixed in writing



  • That doesn't stop some bosses, or some clients.

    <Yes, there's a story there, maybe I'll share later


  • sockdevs

    True, but it does give you a leg to stand on when it shit hits the fan



  • @RaceProUK said:

    And that is why you always get those things fixed in writing

    :rofl:


  • Grade A Premium Asshole

    @RaceProUK said:

    And that is why you always get those things fixed in writing

    As my lawyer always says, "If it isn't in writing, it never happened." You can always send a follow-up email, for clarification (and documentation). ;-)



  • If you break something by refactoring, you're not refactoring.


  • Grade A Premium Asshole

    But if everything keeps working fine while you are refactoring, you are not refactoring. You are just renaming shit.



  • If you're pushing to production mid-refactor, you're not refactoring.


  • Grade A Premium Asshole

    Wtf are you getting on about? Are you drunk?

    But yes, technically you are correct. I would just call that "breaking shit".



  • @The_Quiet_One said:

    because I was in the middle of something, things aren't working right

    If the CTO can see your "refactoring errors" from nowhere near your desk, you're doing something wrong.


Log in to reply
 

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