Tag Info

New answers tagged

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. ...


0

Stay focused. I have had a similar problem for years, but I seem to have finally broken through. For me, one of the projects I was having this issue with, was a code base that had very poor design, or often a lack of design. Also, I am constantly reading blogs and books about good practices. But I also constantly question everything I read, question my own ...


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 ...


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 ...


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 ...


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

Maybe you could create a third project on your source control, which contains only the shared libraries. So in short, your other two projects will reference this shared group of source files. This would allow you to have a group of shared libraries which are self contained, and are not stored within the context of another project. This assumes that you ...


0

Have you considered to use branches? It sounds like you are not going to work on both projects at the same time. You can branch out the second project from the first one and if there is anything you'd like to move to your first project, then you can merge your changes.



Top 50 recent answers are included