Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@ThomasRedstone 'bug' as in taskzilla / issue tracker bug.
It'll become a bug when they remove the old way of starting $important_service
@ipinlnd This might work at some shops but where I work there's a lot of value placed in trust. I'm trying to avoid burning bridges. -
How did you contact your M and Eng?
Make sure all important communications are recorded somehow so that you can refer to them when necessary.
If you guys have a PM system, then describe what you encounter and request for assistance or whatever using that system.
If there is no such thing, use email. Inform your M the situation and CC the eng. Or send request help mail to Eng while cc'ing M.
You said you don't wanna burn any Bridges and the company has trust as a value. That doesn't mean you have to complete whatever task throw at you by all means. That means when you face tasks that you have trouble completing, you have to transparently explain those troubles and seek advices. If your colleagues can't listen your explanation nor give advices, how can you trust them?
Just before the holidays started I was given a task by my manager, $M.
$M: "Kyntak, while I'm away I want you to look into this new way of starting $important_service"
$me: "Okay $M, is there a bug for this that explains what is needed?"
$M: "Yes, you should be able to find it"
Goes looking, finds someone else working on something connected but not the same, finds the code change that makes this available... It doesn't explain how to use it, when the async events fire or (well, to a junior engineer like me) really anything.
Message the other (very experienced) eng.
$me: "Hey I've been asked to make $important_service use the new starting API, can you tell me about?"
$eng: "Yup, here's a bug for that and I'm happy to answer any questions you have" *goes offline*
I read the bug. It doesn't mention the original problem I was trying to solve, it doesn't even mention $important_service. There's no design doc mentioned. The bug has a higher priority assigned than any of my other work. It has an expected completion date only days after I get back from holidays (which $M told me to take).
I try to contact $M and $eng. They've already left for holidays.
"Hmm"
Implements as much of the fairly inevitable boilerplate that I can infer from the bugs and surrounding code.
"Hmm"
So, I'm into my second week of holiday and am starting to think about the potential shit storm I may return to.
I hope the bug's priority was wrong.
rant