good customer service

"Hello sir! Welcome to Walgreens! Is there anything I can do for you? Anything at all?" See that's how it's done. That's good customer service. Try to make things easy on those you serve. Duh! Probably my worst trait as a developer is that I'm bad at merging. I have lived my life trying to avoid tough merges by checking in early and often. If you are going to add three new files to a Visual Studio solution why not make new nude files and then check them in right away so as not to have a merge collision with another developer at the .csproj files you dirtied up before fleshing the files themselves out with code in methods and the like? At my present job we are branching off of a main trunk, making changes and then merging back. This is a first for me. When a branch has been lingering detached from the greater reality for more than a month it is almost impossible to move back, and, you know what? ...it has been deemed better to just make a new branch at that point, splice your changes in, and then sync up that branch. There is just a philosophy that merging shouldn't be painful and that if it is there is something wrong. Most companies gave up on branching a long time ago given a perception that it is painful and instead there is a tendency to dog pile code into a QA branch and then eventually promote the QA branch to another environment when everyone has tested it. Now herein it is really easy to have merge collisions with others if you are not checking in early and often. I guess here too you can always throw away your changes if they have been too long lingering, download code anew, and then doctor your changes back in. This has never really occurred to me until recently as for the most part I've always had a preventative mindset of trying not to get painted into corners where merges are tough. Alas, both two jobs ago and the job before that too I could not check in early and often. I just wasn't allowed and I found myself either doing it anyway and drawing scorn or screwing things up in bad merges. Why such a rule? Code reviews. We have developers doing peer code reviews in both of the tough environments (for me) and a tool like SmartBear Collaborator‎ will force you to look through all of the commits one at a time when code reviewing someone's work. Hence, it is easier to read a code review with SmartBear Collaborator‎ if there is just one big commit. Atlassian Bitbucket's pull request paradigm in contrast will just aggregate all of the commits into something easy for an approver to read and review as a report giving no disincentive for multiple commits and I sure like it better. Having just experienced this it kinda gives me a boost of confidence and takes the weight off my shoulders. It's not so much me that sucks as it is SmartBear. Stupid Bear. Bad Bear. Go hibernate and die Bear. Aaargh! Better tooling please! That is good customer service. This photo of "Tyler" (so her badge says) was taken 3/21/2016.