It's a truism that (many) developers are not good writers. And it's not just style or composition, it's grammar. This has always puzzled me, since if a programmer makes a grammar mistake (using a backtick instead of an apostrophe, for instance), the program won't run. Maybe the problem is that they don't pay attention to the red squigglies in Word.

Here are three rules that, if followed, would take care of about 70% of the most grievous errors I see in blog posts, emails, business proposals, and technical documentation.

I even made a fancy PDF.

Grammar for Developers - Apostrophes

3 Simple Rules

1. Never make a pronoun possessive using an apostrophe
2. Always make a noun possessive using an apostrophe
3. Never use an apostrophe with a verb**

3 Common Mistakes

Right: Unit testing has its benefits.
Wrong: Unit testing has it's benefits.

Right: Carol's code is clean. Her code's style is precise.
Wrong: Carols code is clean. Her codes style is precise.

Right: He runs that backup every day.
Wrong: He run's that backup every day.

Terms

A noun is a specific person, place, thing or idea: Carol, France, house, radish, memory, Chipotle.

A pronoun is a generic, non-specific person or thing. These are the common pronouns: it, he, she, her, them, they.

A verb is an action taken by the subject. He codes. She tests. They demonstrate.

I've been wondering lately about what practices, if changed or improved, will do the most to help a software development team.

Personally, I'm interested in maintainability and automated systems. My question is: how to design so it's as easy as I can make it for someone else to bring my code up-to-date. This is never really just swapping out old stuff. I've been convinced for years that such a nirvana is not only unattainable, but wrong to seek. But having a museum of programming approaches makes technical debt hard to pay. It's not a matter of changing technology, or embracing yesterday's shiny article. It's building into the environment the practice of maintaining old code as a requirement. The adage "if it ain't broke don't fix it" doesn't apply to a software-dependent company (if it applies anywhere). The Japanese word kaizen indicates a better approach: continuous change for the better.

Here are some notes I've made. By doing this, and based on years of experience and study, I came to a conclusion that won't be astounding to most people, but bears calling out.

Improving team communication will yield the biggest long-term benefit in the shortest time.

Key Goals

• Maintain
• Automate
• Test
• Communicate

Key Principles and Practices

• Prefer smaller changes rolled out frequently
• Reduce platforms and frameworks
• Have routine, effective code reviews to improve maintainability and communication
• Ruthlessly improve code to be "as if had always been that way"
• Struggle with naming. To name well requires understanding how others think
• Have routine strategy sessions away from the workplace
• Use in-house templates and libraries for consistency
• Maintain all code as if it were a top-tier open-source project
• Use smaller projects to try new technologies. Either the new project will get normalized, or pieces from it will be applied to existing projects. (Or some combination of the two.)

Key Areas

• Personnel Interaction/Culture
• Security
• Project Management
• Continuous Integration and Deployment
• Source Control
• Testing
• Web UI framework
• Web Api framework
• ORM
• Database
• Architecture (DDD, etc.)

There will be natural overlap in these areas.

Improving which of these yields the most return? I would look at what improves communication first (project mgmt, Agile-based methods, studies on successful teams). Without communication and agreement, it's very difficult to improve other areas. I also think Security needs to be part of everyday work and thinking. Next, CI/CD, Testing, Source Control. Getting CI working will drive a lot of improvements. Then, the stack.

I'll either update this post or follow up on it in a second part.

I have a client who uses Microsoft Team Foundation Server on site, and has been using TFVC version control for about fifteen years. They have a very large codebase with lots of discrete and interconnected Visual Studio solutions.

I've recommended moving to Git, and they're cautiously interested. It would be a large, challenging and time-consuming transition, so for the time being, "interested" means "no."

I couldn't imagine giving up Git. I wondered how hard it would be to use Git locally, but still check in needed commits to their TFS server.

There are a couple of weird things, but using Git and TFVC together is pretty easy.

Important

I've only tested this in Visual Studio 2017, and if you're using Git you shouldn't be using any earlier VS version. You could, as long as you're willing to forego Git Visual Studio integration. Even 2015's integration doesn't work right.

Add to Source Control

This part's simple. You add the solution to the respective source controls as you normally would. With that said, I strongly recommend adding a .tfignore file, as well as a .gitignore.

You don't normally need a .tfignore because Visual Studio takes care of ignoring lots of files. But having one lets you ignore the Git folders.

The .tfignore file can be as simple as this:

.git
.git*

I use one of the standard Visual Studio .gitignore files, then add this:

.tfignore

The standard .gitignore will ignore the $tf folder.

Of course, you can elect to commit the ignore files. For instance, I sometimes keep both ignore files in the Git repository.

Checking In to TFVC

The problem with checking in is that Visual Studio has a setting for Source Control Plugin, and naturally can't figure out whether to use Git or TFVC. The default behavior seems to be that it prefers Git to TFVC.

If you're a Git user, your typical flow with the addition of TFVC will be:

1. Make a bunch of code changes in a branch, committing to your local Git repo several times.
2. When ready to integrate your changes to master, squash the commits, switch to master, and merge.
3. Close the solution.
4. Open Visual Studio, but not the solution.
5. Open Team Explorer
6. Connect to your TFS team project
   
7. I like to right-click on the solution and choose Open in Source Code Explorer. I think this isolates the solution's changes from any other changes in the team project.
   
8. Open Pending Changes
   
9. Be sure to scroll to the bottom and open Exclude Changes.
   
10. Promote the changes as needed. If your .tfignore file is right, these will only be new and project deleted files.
11. Comment and check in. I use the same comment that I used for the squashed Git commits.

Reopening the Solution

You'll usually get the prompt below no matter how you open the solution, and therefore have to open the solution twice. I like opening it right after check in.

1. Open the solution, either from the Start Page, or File > Open > Recent Projects and Solutions. You'll get this message because your Source Control Plugin was changed to Visual Studio Team Services, and VS recognizes that Git source control is available in your solution.
   
2. Answer Yes. The solution will close. Reopen the solution and it should open without error.

Final Thoughts

This has been a huge help to me. I'm able to code effectively using Git's power, but still support my client's environment.

This setup is also a nice way to start showing the value of Git. For example, there's likely to be very little objection to also creating a Git repo on the TFS server, and using that to synchronize long-running branches. It protects the client by ensuring my latest code is available to them, but doesn't force me to use TFVC's ponderous branching and merging.