Skip to main content

Timeline for Employee lack of ownership

Current License: CC BY-SA 4.0

13 events
when toggle format what by license comment
Mar 16, 2019 at 17:22 comment added user87779 @AdrianoRepetti I would agree about that for the comments (and note that your comment on "expectations" IS based on a few assumptions). But the answers should go with different assumptions to broaden the help to people other than the OP as well. Fwiw, I would say the only things we KNOW are that there is a failure in testing and there is a failure in design. The fact is that the most important thing to correct now is testing and BROAD design practices, not one employee's (of 20) performance
Mar 16, 2019 at 16:28 comment added Adriano Repetti @user definitely. That's why I was talking about assumptions. Literally everything or nothing might be true then IMHO we should (mostly) stick to what we know because OP wrote it.
Mar 16, 2019 at 16:04 comment added user87779 @AdrianoRepetti maybe he has, and nothing happened. We're only seeing one side here
Mar 16, 2019 at 14:27 comment added Adriano Repetti I mean: code you wrote and you had plenty of time to test...stopped 90% users to use the service? S* happens but as a developer I'd be ashamed to answer "let's see tomorrow", no matters what my reasons are (especially if I didn't spoke out beforehand).
Mar 16, 2019 at 14:22 comment added Adriano Repetti @Davor because OP didn't mention it (and probably he wouldn't even need to ask if someone did it). We're making way too many assumptions here, I'd love to keep them at the minimum whenever possible. Judging from what OP wrote all I can say is that process should be improved (it always can be) but they have a serious (technical) problem with this senior (whether or not OP is entitled to expect overtime work it really depends on the culture).
Mar 16, 2019 at 12:05 comment added Davor @AdrianoRepetti - who says they didn't? Developers usually get into this cynical phase when they learn that management in their company doesn't listen.
Mar 16, 2019 at 9:49 comment added rkeet Every bug that reaches production is a failure in the testing process - Almost correct. "testing" is part of development. With 20 developers, you should be employing unit / functional testing (preferably both). As such, testing is in integral part of the entire development process, not a stand-alone process. Would reword as : Every bug that reaches production is a failure in the development process. Also, I think you're missing the "management wants features XYZ by ABC". Always a giant domper on proper work. Then you get OP demanding you stay late... then you look for a new job.
Mar 15, 2019 at 19:17 comment added Adriano Repetti I very like this answer but I'd expect a SENIOR engineer to go to the manager to discuss the problem when he is "fed up" with something, to stop doing "firefighting" is not IMHO the response I want to see from a professional experienced engineer.
Mar 15, 2019 at 15:59 comment added 17 of 26 @ChrisStratton Exactly, which is why it is absolutely necessary to understand the root cause of these critical bugs.
Mar 15, 2019 at 15:57 comment added Chris Stratton Sometimes these issues aren't even "bugs" but rather fundamentally wrong design incompatible with the environment in which the code runs; you can fix an endless stream of "bugs" surfaced by the new way that causes breakage every time the code encounters previously unseen (but perfectly compliant) behavior of interacting systems or OS layers, or you can take time to fix the underlying design mistakes.
Mar 15, 2019 at 15:33 comment added shoover And STOP ADDING MORE BROKEN FEATURES until the critical bugs in the existing code are fixed!
Mar 15, 2019 at 13:11 history edited 17 of 26 CC BY-SA 4.0
added 1034 characters in body
Mar 15, 2019 at 12:40 history answered 17 of 26 CC BY-SA 4.0