Tag Info

Hot answers tagged

6

Short answer: No. Longer answer: If your refactorings are truly improvements, then you're engaging in Codependent behaviour - you're supporting your collaborator's bad habits & not giving him/her the opportunity to improve. If your refactorings are trivial, then you're probably wasting your time and/or risking the possibility of falling into an edit ...


5

Yes, but I recommend changing how to go about doing it. Rather than refactoring on your own, do a code review. Work on refactoring and cleaning up the code as a group. You clearly know there are better ways to write the code, so share! Maybe your coworker will learn and start writing better code. In the future, maybe you will not need to spend so much time ...


4

Anything that is a clear indication at all times (not just a splash screen, for instance) when running the application. For WinForm applications, that could be appending "Test" onto the title bar where you have the application name. Another common and more obvious indicator could be the use of colors. A certain window color for production (that you want ...


3

You don't want to check in the IDE created files, as you don't want Thumbs.db or .DS_Store. By making every developer create their own version, you are adding more work and the risk of laziness at absolutely no gain. Having a few extra lines doesn't hurt, and helps you make sure you are not creating files that could interfere with other developers' workflow. ...


3

I can't help you stay focused, but in a team you'd quickly fail code reviews. When you fix a bug or implement a feature on a branch and it comes to review, your reviewer will quickly be saying "WTF did you do that for". I imagine at first you'd be told to stop doing it and the gold plating would be let through "this time", but if you kept doing it, your ...


2

You have to apply some judgment to the situation. If you go off all over the place on dis-related features, that is wrong and not very productive. Also, I once had a co-worker who did that and every checkout from version control was a nightmare for me. If it's dis-related, you should generally log it for later. (I admit, sometimes, I tend to fix it right ...


2

Those sorts of tasks are distracting because they're hard to get out of your head, so get them out of your head. I keep an interruptions.txt file open that I put stuff like that into, or if it's small, I add a TODO comment (which I search for and remove before code review). Then instead of it interrupting my main task just to get it out of my head, I can ...


2

I think its pretty common to get sidetracked on smaller tasks. I actually think its a good habit. It lets to get away from a problem that your facing for a bit so you can later look at it with fresh eyes. But everything in moderation. I don't think you should stop taking on small changes, however I think you need to focus more on developing that feature ...



Only top voted, non community-wiki answers of a minimum length are eligible