My boss is being a stupid cunt. To give you a background we were facing issues with our Collections system. First week December 2019, I and a colleague of mine came up with a new efficient collections architecture. My colleague and I started to Code and create automation scripts mid December and completed it in First week of Jan 2020. This PoC version was supposed to be just between the Dev team(App Dev and Back end, also one from the Ops side to verify the data). I did not receive any feedback on the actual collections system and the data integrity but during this time all they’ve done is take meetings with no real outcome. I raised this and the only email I got is data is looking fine when I know it is not.Now in First week of Feb, he is stressing us to go ahead and deploy the architecture in Production and we have not done any Code Review, Static Code analysis, any real tests on Code and deployment scripts. Have not discussed any metrics for our dashboard and alerting. I have no idea how to handle this cunt. I have even asked for resources to atleast productionalize the code and move ahead the deployment and still no out come. I’ll go in a meeting with him in an hour, I will be very blunt and tell him that whatever he is doing is a foolish way and maybe resign in couple of weeks

  • 2
    Knowing how to handle a cunt is an extremely valuable life skill - in more ways than one
  • 0
    Welcome to devrant
  • 0
    Great first rant and good luck with your meeting.

    What i usually do is 'listen xyz, if you don't do this - as i have recommended you - i am in no way liable nor responsible for any damages, here, sign this waiver of liability. Please interpret this as a very stern warning!'
  • 4
    Great first rant. It's a typical turn of events: Devs build a car made of cardboard (the PoC), and either a manager or customer immediately says "looking great, let's drive this on the highway right now!" ("put it in production"). It crashes and burns, devs say "told you so", manager/customer doesn't understand why it doesn't "just drive" and is angry.

    The takeaway is, the term "proof of concept" means very different things to different people. I recommend not building a big car out of cardboard but a tiny car out of real components instead. IOW reduce the scope radically and implement that with production-ready code from the beginning. Driving on the highway will be slow, but at least the car won't fall apart from the airstream. 😉
  • 0
    @VaderNT Great comparison!
  • 0
    In that situation I'd focus on testing it the old fashioned way mostly and making sure its ready.

    I would also insist on a realistic timeline. Heavy static analysis can be dropped in most cases.

    Someone needs to look over the code but you need to be careful with code review as that tends to include a review in general.

    Your review needs to be targeted and you need to keep track of tasks that can be deferred such as code aesthetics.

    Anything you put back you have to let them know that time has to come out somewhere and sometime sooner than later.

    Avoid gaining time by cutting corners just rearrange things then be clear you're not doing it in less time just getting it out sooner.
Add Comment