4 ms·
In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. Ther
by jcon321 3y ago
In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.
- peteradio 3y agoIt was in dev environment which I doubt in his world required any sort of management approval.
- dxdenton 3y agoI agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.” > There’s always a way to get housekeeping items approved… Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).
- jcon321 3y ago> I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. I feel your pain then.