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 |