Timeline for How to deal with a senior coworker with potentially bad work habits?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 17, 2019 at 20:42 | comment | added | user34687 | @ThorbjørnRavnAndersen no, GDPR is not a separate issue - if you have access to production then you have access to real PII in most cases. Thats a GDPR issue. And you really should be striving to reduce the differences between your dev environments and your prod environments because that eliminates the very point you are trying to use to prop up your position. If your prod environment has characteristics that only manifest in prod, then your setup is baaaaaaaad and should be fixed - and anyone telling you otherwise should be sacked. | |
| Nov 17, 2019 at 20:29 | comment | added | Thorbjørn Ravn Andersen | @moo gpdr is a separate issue. Production is very rarely 100% identical to the other systems and may have characteristics that you can only identify with access. | |
| Nov 17, 2019 at 19:18 | comment | added | user34687 | @ThorbjørnRavnAndersen nope, not on any sort of a regular basis - that would be a violation of the GDPR for one thing, and a failure of your dev, test and staging environment setups for another. Production should not be a unique unicorn environment, it should be identical to the other environments your devs work in otherwise you are introducing problems. | |
| Nov 17, 2019 at 14:19 | comment | added | Thorbjørn Ravn Andersen | Developers should be able to access production systems but not able to change anything. There might be very valuable information not easily accessible otherwise. | |
| S May 27, 2017 at 20:03 | history | suggested | Glorfindel | CC BY-SA 3.0 |
grammar corrections
|
| May 27, 2017 at 19:16 | review | Suggested edits | |||
| S May 27, 2017 at 20:03 | |||||
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://workplace.stackexchange.com/ with https://workplace.stackexchange.com/
|
|
| Nov 8, 2016 at 19:36 | comment | added | Raydot | I am in a similar position with a similar problem. I would not do this mostly because 1) we simply don't have enough developers for me to alienate to begin with and 2) the problem most of the time is not developers but project management wanting everything yesterday but we are moving towards this kind of system mostly for very similar reasons. | |
| Nov 8, 2016 at 12:04 | comment | added | Lightness Races in Orbit | @angarg12: Within reason, sure. Upending your entire company's workflow because someone is refusing to follow simple directions is backwards, though. First, get your people in line. | |
| Nov 8, 2016 at 10:14 | comment | added | angarg12 | @LightnessRacesinOrbit trying to solve personal and cultural problems with processes and procedures should be the first step. Not only will address this specific case but it will avoid repeating it in the future. | |
| Nov 8, 2016 at 9:22 | comment | added | Peteris | @LightnessRacesinOrbit on the contrary, I'd feel that solving the problem with one person does not solve the long term problem. it will eventually repeat even without a "semi-malicious actor" as in this case, but from accidents or well-meant actions in a hurry and you need to fix your versioning and deployment process to fix that. | |
| Nov 8, 2016 at 3:19 | comment | added | user56728 | If it's a small team (two or three developers who each wear many hats), sometimes you don't have a choice but to give them all production access. But with such a small team, each member should trust each other 100% and there should be processes in place that prevent this behaviour from occurring. It seems like this 'senior' developer is not trusted. That's the biggest problem now. | |
| Nov 8, 2016 at 0:16 | comment | added | Peter | @djechlin Thx. added answer and removed comment | |
| Nov 7, 2016 at 23:32 | comment | added | Lightness Races in Orbit | This answer is suggesting a huge change to processes and technology, without actually addressing the real problem, which is that the employee is flagrantly refusing to follow simple and clear directions from his supervisor. Persistently. Over the long term. Sack him. | |
| Nov 7, 2016 at 18:07 | comment | added | user42272 | @Peter well, I voted to reopen fwiw. | |
| Nov 7, 2016 at 9:51 | history | edited | user34687 | CC BY-SA 3.0 |
added 1295 characters in body
|
| Nov 7, 2016 at 9:34 | comment | added | RemcoGerlich | This is a good future system to aim at, but it doesn't solve the immediate problem, as it needs to be implemented first, presumably by the current developers. | |
| Nov 7, 2016 at 7:28 | comment | added | user42272 | @jpmc26 idk, at my company cleaning staff just wash dishes. so we somehow never have to deal with a**holes who don't wash dishes. but my college residence had that problem and it was a big problem. sounds like someone failed to teach this guy what a good build process is when he joined and now he thinks he can run stuff. a mistake was made in hiring or training. Moo's answer will prevent part of the problem for the next hire. | |
| Nov 7, 2016 at 7:04 | comment | added | jpmc26 | @djechlin The only way you can "not have problems" is by having a team that knows how to prevent them. This developer won't contribute to that, unless he changes his approach drastically. A company is just people; its policies are made up of the decisions of those people. | |
| Nov 7, 2016 at 6:51 | comment | added | user42272 | @jpmc26 I agree with all of that. I did upvote this answer for contributing real, useful and even technical information to the problem. In general good companies are better at not having problems then in dealing with employees who do have them. Again this isn't the answer to the problem, but it's very good, relevant information. | |
| Nov 7, 2016 at 0:25 | comment | added | Jim Garrison | And if the maverick developer decides to quit over losing production access, you are probably better off. | |
| Nov 6, 2016 at 23:17 | history | edited | user34687 | CC BY-SA 3.0 |
added 352 characters in body
|
| Nov 6, 2016 at 21:49 | history | answered | user34687 | CC BY-SA 3.0 |