Timeline for How do I take responsibility for my code when colleague makes unnecessary improvements without notice?
Current License: CC BY-SA 3.0
43 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 17, 2016 at 20:59 | answer | added | gnasher729 | timeline score: 1 | |
| Apr 17, 2016 at 11:54 | history | edited | gnat |
http://meta.programmers.stackexchange.com/questions/7285/structured-tag-cleanup-initiative-phase-ii
|
|
| Dec 22, 2015 at 19:51 | history | edited | Jesslyn |
It's like you said in your comment, "it's about interacting with people in the workplace."
|
|
| Dec 22, 2015 at 19:46 | comment | added | Jesslyn | @Ixrec meta.workplace.stackexchange.com/questions/1767/… | |
| Dec 21, 2015 at 15:42 | review | Close votes | |||
| Dec 26, 2015 at 19:46 | |||||
| Dec 21, 2015 at 15:36 | history | protected | user40980 | ||
| Dec 21, 2015 at 15:35 | history | edited | Ixrec |
edited tags
|
|
| Dec 21, 2015 at 15:24 | comment | added | Ixrec | I'm voting to close this question as off-topic because it's not about programming, it's about interacting with people in the workplace. | |
| Jun 28, 2013 at 20:22 | review | Suggested edits | |||
| Jun 28, 2013 at 21:23 | |||||
| Jun 28, 2013 at 20:08 | history | edited | Tulains Córdova |
edited tags
|
|
| Apr 10, 2013 at 15:12 | history | edited | Jesslyn | CC BY-SA 3.0 |
fixed grammar
|
| Apr 10, 2013 at 15:06 | history | edited | Jesslyn | CC BY-SA 3.0 |
Added additional clarification to address question in comments
|
| Apr 10, 2013 at 3:18 | comment | added | Cliff | @Jesslyn - Is your team lead at all concerned that your teammate is spending time making unnecessary improvements to old code? At the least, it seems inefficient for your teammate to be spending time making unnecessary changes as opposed to working higher priority tasks. In addition, if your teammate prefers to spend time "fixing" your code for you rather than empowering you to do it yourself, that seems pretty inefficient as well. Have you discussed any of these concerns with your team lead? | |
| Apr 6, 2013 at 13:54 | history | tweeted | twitter.com/#!/StackProgrammer/status/320535015584833536 | ||
| Apr 5, 2013 at 14:47 | history | edited | Jesslyn | CC BY-SA 3.0 |
added clarifications to question, so that I may clean up my comments
|
| Apr 5, 2013 at 14:34 | comment | added | yannis | Hey all, this discussion is getting a bit long, and comments aren't suitable for extended discussions. Jesslyn the better way to respond to comments asking for clarifications is to update your question instead of adding yet another comment. Comments are not that visible and it would be a shame for your clarifications to be lost in the noise. Everyone else please refrain from side discussions in comments (our chat room would be the better place for those), only post comments if you want further clarifications from Jesslyn. | |
| Apr 5, 2013 at 6:26 | comment | added | Adronius | How can words "unnecessary" and "improvements" can be used in one sentence? Every code, you wrote, is not practically your. It's code of company, so every developer shares the same code. Do code reviews and every change should be agreed upon. | |
| Apr 5, 2013 at 5:53 | answer | added | Sandeep | timeline score: 0 | |
| Apr 5, 2013 at 5:22 | comment | added | hyde | @Mikey What's wrong with it is combination of that "if" you say, combined with there being a better way. Just because cutting trees with an axe used to be how it's done, modern chainsaw is still better, and a must if you do it professionally. Using a VCS systems which does not support easy branching and merging, or not using those features in team projects, is a lot like using an axe instead of a chainsaw, in my experience-based opinion (how to use them right is then a broad subject, and they can be used wrong, of course). | |
| Apr 5, 2013 at 1:53 | comment | added | Vector | @hyde - nothing wrong with checking in unfinished code if it doesn't break the build and isn't callable by others. Just because code is checked in doesn't mean it's going to run, even if it's built. A lot depends on the context as well - are we dealing with a corporate evironment, a custom/botique software shop, an SAS provider etc. | |
| Apr 4, 2013 at 23:36 | comment | added | Vector | What sticks out to me here is "and he's not been responsive". Red Flag IMO - something not OK with that guy. | |
| Apr 4, 2013 at 23:33 | comment | added | user16764 | If I wanted to fix your code, I would do it, then push it as a separate branch and ask you to review it. Is the problem that this person fixed your code without consulting you, or that this person deployed the fixes without talking to you first? | |
| Apr 4, 2013 at 17:35 | comment | added | Dunk | I would also add that once many people on the team get involved in hacking up the initial code, it invariably ends up being better than when it started and reusable in more situations. | |
| Apr 4, 2013 at 17:28 | comment | added | Dunk | If a bug is discovered in a class that requires investigation then whoever modified the file last is usually told to investigate the issue. However, if the person is not even on your project so that you can't assign him/her the task of fixing the issue then that would complicate matters, which might be the part I missed. But even so, unless you have a formal Problem Report Tracking system and these changes are being tracked against that then I can't see how his changes could reflect negatively on you unless he is also complaining to your lead while making the changes. | |
| Apr 4, 2013 at 17:27 | comment | added | Dunk | @Jesslyn-In the past, we had done code reviews as modules were initially completed. The problem is that once code is reviewed, it is considered locked down and can only be changed via Change Requests. This resulted in minor bugs/ugly code/other issues to remain in the codebase because the pain to fix was to high. Now we wait as long as possible to do code reviews, usually after a module is solid and works with other modules that are being developed. This gives the freedom for people to change code, fix minor bugs, cleanup code as they integrate. | |
| Apr 4, 2013 at 15:41 | comment | added | Jesslyn | @Dunk, can you explain how your team does code reviews? Your team sounds very forgiving. You mentioned that the last developer to touch the code gets the next task, is that even when all they did was a small cosmetic change or only done minor changes in the project and are not considered the project expert? | |
| Apr 4, 2013 at 15:19 | comment | added | yannis | @Jesslyn That's not always how it works. Code reviews are a team activity and how exactly they are conducted highly depends on the team's structure, dynamics and... ahem... culture. There's no one size fits all solution, if you really want code reviews to be as effective as possible you have to sit down with your team, discuss, and decide what approach is best for you. | |
| Apr 4, 2013 at 15:19 | comment | added | Dunk | @Jesslyn-You also said he's 2nd in command. Maybe part of his role in that regard is to ensure that ALL the code is up to his expectations. Where I am currently working, while we are in development, we have an environment where everyone owns the code. People are free to change whatever they believe needs changing. Nobody is offended or takes it personally that somebody changed code that they may have written. The worst someone gets is jokingly ragged on for breaking something. The only problem I see in your situation is your choosing to be offended instead of just moving on to your next task. | |
| Apr 4, 2013 at 14:40 | comment | added | Jesslyn | @Dunk, in my question I stated that my colleague had no development assignments in the same project--he was only responsible for reviewing code. I believe one of the points of a code review is to involve the programmer whose code is being reviewed/changed. | |
| Apr 4, 2013 at 13:46 | comment | added | Dunk | I don't see any problems with developers changing your code as they see a need while doing there own development, regardless of who wrote the original code. Especially during development. Changing code on fielded systems is another matter entirely. The only caveat I would add is that at my place there's an unwritten rule that last person to modify also gets assigned the task of fixing whatever new problems are discovered with that file, whether their change caused the problem or not. | |
| Apr 4, 2013 at 4:57 | answer | added | yannis | timeline score: 86 | |
| Apr 4, 2013 at 2:07 | answer | added | Vector | timeline score: 4 | |
| Apr 3, 2013 at 21:44 | history | edited | gnat | CC BY-SA 3.0 |
personal stuff removed
|
| Apr 3, 2013 at 21:20 | comment | added | hyde | Of course this depends on what VCS you use, but that might be something to look into, starting to use branches more. With personal branch, it's IMO great when you can commit (and push with DVCS) whenever you feel like it without worrying, and merge only when done with a part, or merge only partially when necessary (a good DVCS makes this pretty easy). Also works great with code review, being able to naturally do it and fix issues before merging. | |
| Apr 3, 2013 at 21:05 | answer | added | kevin cline | timeline score: 19 | |
| Apr 3, 2013 at 19:43 | comment | added | hyde | Why do you have non-finished changes in a shared branch? That's a bad idea, and not just for the reason you have encountered. | |
| Apr 3, 2013 at 18:51 | comment | added | Carolyn | In my org, all code changes are supposed to go through a review of some kind, and it's considered poor form to check in a change without noting in the changelist description who the reviewer was. Introducing that principle in your org might be a long-term solution to the problem of coworkers checking in changes to code you wrote without review. | |
| Apr 3, 2013 at 18:20 | history | migrated | from workplace.stackexchange.com (revisions) | ||
| Apr 3, 2013 at 18:10 | answer | added | user606723 | timeline score: 4 | |
| Apr 3, 2013 at 16:33 | vote | accept | Jesslyn | ||
| Apr 3, 2013 at 16:26 | comment | added | MDMarra | Do you use git, CVS, or TFS for your code repo? Just roll back his commits. He'll get it eventually :) | |
| Apr 3, 2013 at 16:04 | answer | added | Michael | timeline score: 79 | |
| Apr 3, 2013 at 15:56 | history | asked | Jesslyn | CC BY-SA 3.0 |