Just found out the backend developer I’m always complaining about. The one who:

- Can’t implement OAuth, and we have to have app users login every 24 hours because we have no way to generate new refresh tokens.

- Who used the phrase “your time zone is not my concern” to avoid building something that would let us inject test data.

- Who’s been debugging a critical bug affecting many users since December.

- Who can’t conduct API tests from external internet (you know, like the way the app will be in the wild) because it takes too much time.

- Who replies to Jira tickets only on a blue moon.

- Who has been 90% of the reason for my blood pressure situation

... is a fucking principal engineer in this company. In pecking order, his opinion should be considered more valuable than mine and everyone on my team.

I’ve just lost the will to live. How are big organizations THIS bad. Seriously, what promotion discussion did he go into

“So, you are a complete and utter bastard, nobody can stand to speak to you and you’ve yet to deliver anything of worth that actually works, over the course of several years ... ... ... interested in having your pay doubled??”

  • 5
    Wooow, what a jerk
  • 3
    Is this the same useless skidmark from before?
  • 12
    Maybe he's good at company politics. Knowing when and where to lick ass, how to grab credit for others' work and how to shift blame for his failures.
  • 3
    timezones?? why not using timestamp instead?

    oh well, assholes like that don't care about others.

    I would punish him with writing complex responsive CSS layout with IE11 support to match the design of his boss designer who has his behaviour and same level of knowledge in his area of work!
  • 1
    Maybe he knows somebody...
  • 1
    @legacyJanitor and in which timezone is the timestamp?
  • 2
    He might have blackmailed someone
  • 0
    @sSam you are right, there is effort needed to include and configure lib for converting timezones, but I guess this asshole won't bother anyway
  • 0
    @AleCx04 unfortunately no, that skidmark was on the product/business side of things. This is an engineering skidmark
  • 0
    @Fast-Nop no he's not. I think its a "too critical" kind of situation. He's the only one working in a certain area. Given how complex and non-sensical his code is, i'm not sure anyone would ever be able to replace him
  • 0
    @legacyJanitor different kind of "timezone" issue. Something happens at a given time everyday, its middle of the night for us, we can't test it locally without being online 24/7. Theres no ability in QA to change the time, replicate it, fake it etc. Request was for some way for us to test this in QA in our timezone .... and we were told no #teamwork
  • 1
    @iamavalos every language and platform have some inbuilt or third party solution to support OAuth.

    Finding a solution is not a problem. Having someone competent to use one, is
  • 0
    I'm currently in the same position. My fellow co-workers always seem to favor the opinion of the guy who works here longer than me regardless of the arguments
  • 0
    So the guy stayed quiet, do nothing and just got promoted to better position.
    Sorry for being rude but...
    Do you have remote job with those standards ? 😂
  • 1
    Why are new refresh tokens required to be generated and how is that relevant to having users login every 24 h?
  • 0
    @practiseSafeHex no possible mocks for QA? we gave access to paw(postman alternative for mac) to our QA team with prefilled mocked requests so they can work effortlessly on their test instance any given time. this setup is we did is almost no brainer. we had feature that required backend to make request to third party api once a day and then cache it. on test instance it was like 5 minutes as QA team asked! i am very much sorry that you have to deal with that kind of bullshit! polish up your portfolio, go find better boss! this is insane!
  • 0
    @asgs login generates an auth token and a refresh token. Auth token expires in 2 hours, refresh token expires in 24 hours. (Times differ between implementations and needs)

    Standard OAuth is to have a mechanism to get new refresh tokens. So, so long as someone is still using the app the tokens keep them logged in while being different everyday. Depending on your app / flow. This might be sending a new refresh down on every request, or having an endpoint dedicated to getting new ones.

    We have nothing. When the refresh token expires, there is nothing the app can do but logout and ask the user to log back in.
  • 2
    @legacyJanitor we do have mocks. We have to create them ourselves. But it’s very difficult. There’s a huge amount of business logic. The same API will send down different things depending on the time of day, who has interacted with it, something different will happen if nobody has, or 50% has. It’s also changing very rapidly.

    It would be significantly more effort on our side to build something that actually mimics the backend rather than just static mocks. It’s too much effort for us. We’ve asked that the backend team provide some custom test API’s for us to inject data and start a flow.

    After almost a year we have 1, I’d say we need a minimum of 10 at the minute, but ideally a lot more. They have refused and say they don’t have the time
  • 0
    @practiseSafeHex I think I missed the "we have nothing" in your rant
  • 0
    Almost all things in Go are well designed the big exception is the Oauth library. If refresh token gets renewed after use (what every good implementation should do) you are screwed
Add Comment