This will work!



  • I'd been assigned to spec out an interface between two components which will be coded in C++. I used the PIMPL idiom, and because we will have different underlying thingies to deal with, the base implementation class is pure abstract. I put together some code that compiles, with stubbed-out concrete implementations of the abstract class, that would execute. I then sent the code out for comments.

    My rookie manager (former lead developer) and I had a conference call with some off-site colleagues who will also be working on the project. We spent a lot of time discussing what we are going to do short term and long term with the thing we are building, then finally started to the subject of the interface.

    I noticed that my boss was quickly jotting down pseudo code in his notebook. Without any mention of my stuff, he started with "here is what will work for our interface." Not "what you did sucks" or "we can't really use it" or "it does not address blah blah blah". Instead, we were charging off into back-of-the-envelope land. I was not a happy camper.

    Now my boss is mad that I got mad. On the plus side, we did finally start talking about the work I did and some changes to make to it.

    Probably TRWTF is my total lack of people skills for dealing with shit like this, but at this late date in my career I don't think any amount of training would keep me from seeing red in this situation. :-(



  • Oh my, a lead developer becoming a manager, it is like watching a Jedi fall to the Dark Side of the Force.


  • Trolleybus Mechanic

    @rstinejr said:

     _________________________________________________________________________
    /                                                                         \
    |      Probably TRWTF is my total lack of people skills for dealing       |
    |     with shit like this, but at this late date in my career I           |
    |     don't think any amount of training would keep me from seeing red    |
    |     in this situation. :-(                                              |
    \_________________________________________________________________________/
       |/

     

    My brain cannot parse your story and your avatar at the same time. :|



  • @Lorne Kates said:

    My brain cannot parse your story and your avatar at the same time. :|

    My headmeats were working fine to parse it till you did the speach bubble on the avatar.  Why must you try and break my brains?



  • Oh I get it, the real WTF is writing new software in C++ in 2012. LOL good one. C++!



  • @rstinejr said:


    I'd been assigned to spec out an interface between two components which will be coded in C++. I used the PIMPL idiom, and because we will have different underlying thingies to deal with, the base implementation class is pure abstract. I put together some code that compiles, with stubbed-out concrete implementations of the abstract class, that would execute. I then sent the code out for comments.

    My rookie manager (former lead developer) and I had a conference call with some off-site colleagues who will also be working on the project. We spent a lot of time discussing what we are going to do short term and long term with the thing we are building, then finally started to the subject of the interface.

    I noticed that my boss was quickly jotting down pseudo code in his notebook. Without any mention of my stuff, he started with "here is what will work for our interface." Not "what you did sucks" or "we can't really use it" or "it does not address blah blah blah". Instead, we were charging off into back-of-the-envelope land. I was not a happy camper.

    Now my boss is mad that I got mad. On the plus side, we did finally start talking about the work I did and some changes to make to it.

    Probably TRWTF is my total lack of people skills for dealing with shit like this, but at this late date in my career I don't think any amount of training would keep me from seeing red in this situation. :-(

    If he is a new manager he may not be completely comfortable in his role yet. What I would suggest in your situation is to let things cool down, then one day when he is in a good mood have a talk with him to prepare a RACI chart. It does not have to be very complicated, you just want a chart that says that while you welcome his input ("C") you are the one who is making the technical decisions ("R"); but make sure that his role is clearly indicated and that he is not let aside (i.e.: don't try to put him in a "I" role only). If he has a technical background it is possible that at some point in the future his opinions will prove valuable.

    The power of a RACI chart is that it is visual and it is a formal artifact (unllike an email going over roles & responsibilities). This is very effective yet simple.





  • @rstinejr said:

    My rookie manager (former lead developer)

     @rstinejr said:

    I noticed that my boss was quickly jotting down pseudo code in his notebook.

    I suspect you've spotted the issue there.

    Your manager should be managing you, not managing code. He ain't severed the apron strings yet.

    His job should be to ensure you write it, not have him write it himself. If he's doing your job, he's not doing his. And you're not doing yours.



  •  

    I used the PIMPL idiom,

     

    TRWTF.



  • @pure said:

     

    I used the PIMPL idiom,

     

    TRWTF.

    Not at all. PIMPL is a solid and proven approach for separating implementation from interface in C++. WTF else would you suggest?



  • @rstinejr said:

    Not at all. PIMPL is a solid and proven approach for separating implementation from interface in C++. WTF else would you suggest?

    If forced to work in C++, I think I'd choose seppuku.



  • @rstinejr said:

    Not at all. PIMPL is a solid and proven approach for separating implementation from interface in C++. WTF else would you suggest?

     

     

    Normaly people choose C++ bcause they can use classes for that. PIMPL is more a C idiom.

     

    But them, it is hard to criticize. We have no idea of the requirements.

     



  • @Mcoder said:

    Normaly people choose C++ bcause they can use classes for that. PIMPL is more a C idiom.

    Again, I disagree. PIMPL makes plenty of sense if you have classes, want to share a header, but don't want to expose the implementation, or at least very much of it. See ramdom Google hit sayng PIMPL is only useful for C++



  •  @Lorne Kates said:

    @rstinejr said:

     _________________________________________________________________________
    /                                                                         \
    |      Probably TRWTF is my total lack of people skills for dealing       |
    |     with shit like this, but at this late date in my career I           |
    |     don't think any amount of training would keep me from seeing red    |
    |     in this situation. :-(                                              |
    \_________________________________________________________________________/
       |/

     

    My brain cannot parse your story and your avatar at the same time. :|

    It's Chessie sleeping in air conditioned comfort... unlike us sitting in our always too-cold or too-hot offices.

     



  • @operagost said:

    ...It's Chessie sleeping in air conditioned comfort...

    Bingo!



  • pImpl is normally used to separate a concrete class from its implementation, not an abstract one. The big issue I find with pImpl on the whole is that the outer class has to manage the pointer of the inner class, so it is either

    - unique: your class is non-copyable. However you cannot use auto_ptr or scoped_ptr so your class must do the actual delete. This is not a major issue, and works when your class is quite heavyweight. The only issue is that you then will often have yet another shared_ptr to wrap your "unique" class.

    - you need to wrap a shared_ptr.

    The alternative to pImpl is an abstract base class and then you pass around shared_ptr<MyInterface> which holds an underlying MyImplementation. Of course all the "implementation" is now virtual (or non-virtual calling virtual) and you may well have only one implementation.

    The plus side however is for test-driven programs you may wish a second implementation anyway which is just a prototype, and it is also easier to move your class forward by writing a new implementation which doesn't require recompiling the code that uses the class as the interface doesn't change, the only thing that changes is the factory that creates the actual class.

    If your manager wrote out an abstract interface and told you to write implementations of it and pass around shared_ptr they might actually know what they are doing.

    pImpl will probably work better in C++11 where there are move semantics so you can return the actual class from your factory object by moving it even if it is non-copyable, as well as being able to use unique_ptr to wrap the pImpl itself.

     


Log in to reply