In Part One I outlined the goals of this series. This article will go over what eventually happened when I decided to rework my source control system. As of the beginning of this process, I have a bit of a mixed architecture in regard to source control. For my open source project (which I’ll reveal in a later blog post once I’ve cleaned up the code enough for it to not be embarrassing), I use github, as I find it to be the best place to host that sort of thing. For my internal projects (hacky scripts for various things, websites for other people, utility code, etc.), I tend to use VisualSVN, which is currently running on my “server”. Finally, for an upcoming partner project, I’m using Bitbucket. All three approaches work rather well, but I’m mostly irritated with Subversion. I had initially intended to keep source control on my internal server, but after some thought, I realized that really adds a lot of work I’m not interested in doing. Specifically, the following are the issues I have with it.

Someone pointed out to me the other day that I am a bit of “an old fart” in the .NET development space. At first, I was about to protest and insist that I wasn’t that old. Then it occurred to me that I have been using .NET since the first public beta, which came out in 2001 (if I recall correctly, which I may not, because I’m old). That said, as I think back over my career and the loads of developers who eventually got out of the industry, I wistfully contemplated giving some advice to the folks just getting started. The reasons for it are many. First, I want to see more people succeed. Second, I’ve watched loads of people fail (or worse, not rise to the full level of their potential), including screwing up via self-sabotage. Here, then, are some things that I’ve noticed that might serve as “lifehacks” for making your climb through your career a little easier as well as making your survival more likely.

I find that on many projects, the most psychologically draining part of the whole experience, other than the final sprint before the thing is completely finished is the first little bit of code to get started. It’s both simple and tempting to open a new project and just start slinging code, but it also frequently complicates things later on. Therefore, I’ve long since come to the conclusion that I should have a fairly standard way of approaching the setup of projects, both for myself and for external clients. I’m going to start writing a series showing how to implement the things you need to have a reasonably decent home development setup. I’m not going to cover what kind of desk or chair to get, as I’ve had the same desk for 14 years and pick chairs based largely on how comfortable they feel in the store with a reasonably similar desk. No, I’m go to get into the guts of how to get a working process together to develop software in your house with professional-grade discipline so that you can actually complete what you set out to do. I’ll be doing these piecemeal as I get a more regimented environment set up at my own house, so feel free to follow along and change anything that doesn’t suit your needs/desires.